As with my previous "vs" question at BlackBerry: Overriding paint() vs subpaint() I am wondering if this has to do mostly with convention, style, or if there are some real hard n fast rules.
The way I've seen it so far is that MainScreen.setBanner(Field) and MainScreen.setTitle(Field) have almost exactly the same functionality. I have used the case of being able to call setTitle(String) in a simple UI. However I am working across iOS, droid, BB, and try to make the UIs similar - my title/banner is a 'pretty' custom manager.
The only difference I can see is the little style element that is inserted automatically under a title.
Is this the only reason I would have to choose between using each of these methods?
Perhaps there are stylistic or convention reasons to use one over the other? Perhaps RIM has some intentions with these methods that I cannot yet see as a new BB developer? Am I making a mistake by treating these methods as direct substitutes?
If you use both, the banner is laid out above the title. My understanding is that if you are using only one, then they are pretty much interchangeable -- the reason to have both is that you can get some stacking behavior if you want to add more information to the top of the screen.
There is an article: "MainScreen explained" that goes into detail on this and other features of MainScreen.
Related
I am a novice iOS app developer. Basically i need to listen for any change in the UI (e.g., doing something on text change in textviewUI), and update UI to reflect any model change. I was looking into different technologies available for binding and am bit overwhelmed.
I know this is very subjective, but i would like to hear your suggestions on it (for swift and objective c both)
Also any pointers to the best practices would be really helpful.
Welcome to iOS! Cocoa (Touch for iOS)- Apple's framework- has some design patterns you will want to learn...
These include delegation and target/ action. Quickly summarized: delegation is handing some responsibilities off to an object that can take care of them. This provides methods you can use to get stuff (like changes) to that object. Read this link to learn more about delegates: https://useyourloaf.com/blog/quick-guide-to-swift-delegates/
Now, back to the text field example. A handy method in the UITextField delegate called textField(_:shouldChangeCharactersIn:replacementString:) will be called whenever the text field is going to change. As for target/ action, that's google-able. Is that a word? As for any pointers, learn MVC. Have fun!
I’ve been a procedural programmer for a long time and most of my iOS code is written with lots of if statements instead of sub-classing. I think I finally understand how to write object oriented code but I have a few questions.
I have a class, ScoringToolbar.m that is used in all of my games. It creates buttons for the bottom of the screen. Which buttons are created vary depending on the game and the options in the game. Here’s a typical screen.
Right now it is a long series of if statements. In addition to being hard to read, it’s definitely not proper object oriented programming. What I’d like to do is convert the class into a superclass and add a subclass for each game. My first question is: Is there a convention for naming the superclass?
Also, I’d like to keep the ScoringToolbar.m name for each of my sub-classes. If I create one sub-class for each of my apps (or group of similar apps) I can move the code from the if statements into it. Then each app would call its own subclass and create the buttons it needs. If I do that I won’t have to change any of the calling code. However, if I have lots of .m files with the same name, what do I do with the .h files. Do I have just one and make sure it works with all of the .m's. Or is there a way to tell Xcode to use a specific .h file in an app?
Or is this the wrong approach altogether?
I'm not sure subclassing is your best option. Your question about multiple .m files with the same name suggests this approach might get confusing. You might want to think of your ScoringToolbar as a control that your apps configure for their needs. In this way it wouldn't be much different than a UIButton. Each app would be responsible for creating an instance of the ScoringToolbar and setting it up to suit. It could do this in a method in an existing class or in a helper class. The ScoringToolbar takes care of rendering the UI (icons, colors) while the calling app indicates what options it needs (up/down votes, number correct/incorrect, etc).
I think subclassing is not a good option for you problem. You will end up with code which is hard to maintain and modify when your apps or no of apps grow big.
Have a look at some design patterns, if I got your problem correctly, builder pattern would be one of the options.
Or you can create configuration file for each game. For example you can have an array of dictionaries in a plist. Each dictionary will represent a UI element in the toolbar. For example you can store the image name, order, selector, position(?) and etc in the plist. When loading the application you can create the toolbar elements at run time using the dictionary options.
These are just a starting point but based on your requirements and extendability of your apps you can find better solutions.
Hello I am building forms over and over in iPhone and iPad apps:
Custom UITableViewCells for labels with input
Localization for labels, placeholder text and section headers
Validation that marks the cells red or something and does not allow "Submit" if form is incomplete
Clicking in the cell activates the editable text box
Next / previous buttons
Reliable across devices, orientations, iOS versions
I can't imagine I'm the only one doing this. Is there a mature framework or something that can drop in and use? Could you please comment on how you use this library with designs other than vanilla UITableViews with your own colors etc.?
Take a look at IBAForms - an open source project from from Itty Bitty Apps. I haven't used it yet myself, however I believe it does most of what you want, except for validation. Here is the github page: IBA Forms
It hasn't been maintained in a while, but if you're looking for a forms library - it's mature and works. At the very least, it could be the starting point for something you take further.
Update: There is also Chris Miles' EZForm library, which is very nice.
Update #2: Have also started checking out QuickDialog, which seems to be very popular.
Update #3: Nick Lockwood has created one called FXForms
Update #4: Martin Barreto has created one called XLForm
I don't know if this counts as an answer, but i use Sensible Cocoa - Sensible TableView (STV) for this purpose a lot. It's not a "forms" framework (on top of UITableView) as such, but it can be used for this purpose in a very flexible way. It still requires some coding to build a full-fledged form but the UITableView/UITableViewController boilerplate code is reduced to a minimum. Unfortunately the developers bumped the price tag quite high with version 3.0, so i'm actually looking for a STV replacement right now. (I'd stick with STV if it wasn't for the price!)
I don't know of anything that combines all those features, but I recently open-sourced my validation library PMValidation on github, which I used developing the iPhone app Imprints. PMValidation comes with many basic types suitable for validating forms, and in fact that's what I originally built it for.
Using the PMValidationManager class you can easily listen to UITextViews or UITextFields, and update whatever graphical widgets you want via notifications. It's very modular and easily extendable, should you have more unique needs. It's under the MIT license.
I was looking into creating iOS-apps (especially for the iPad) with the Adobe-Flex framework. It looks very promising to code apps this way.
Is it possible to create own controls/widgets? In the far future I might want to create my own kind of gantt-calender or whatever. Is something like this possible and are there any good tutorials/book out there?
Thanks in advance!
UPDATE: I want to create iOS Components that I can use in Flex. Controls, that are not aviable by default in Flex. Is that possible? By derivating or something?
UPDATE 2: In the meanwhile I found FlexLib to be useful. How hard is it to create stuff like this on your own? Especially for mobile devices. Are there any good tutorials, books, etc. out there?
Yes, you can create your own Controls in Flex. They are commonly called Components. I suggest you start by reading the Flex Docs on how to do so. There are also plenty of other resources out there. One is a screencast series that I created for The Flex Show. Here is episode 1.
You had asked:
How hard is it to create stuff like this on your own?
It depends on what the component wants to do. The commercial components we've built at www.flextras.com have taken from three to twelve months to build. Our Calendar is built from scratch, but most of the other components extend existing Flex Framework components.
The Flextras stuff are architected for reuse. A "single use" component for a specific app can be built in 1 hour [and up].
Once again, the purpose of a component will affect how long it takes to build.
#chiffre
Ok, maybe I am guessing wrong but "iOS controls" makes me think not to "flex controls".
Anyway with Flex 4.5.1 you can add any controls you want, the only thing that you must count (and this counts a lot) is performance.
Read especially about item renderers since scrolling list is not so fast on iOS and how you can make use of cacheAsBitmap.
Also keep in mind to always use light controls when needed if not extend base controls like UIComponent or Sprite and not Button if you just need a rectangle.
Here are some links
http://blogs.adobe.com/flashplayer/2011/06/adobe-air-2-7-now-available-ios-apps-4x-faster.html
http://www.adobe.com/devnet/flex/articles/mobile-development-flex-flashbuilder.
I am working on BlackBerry user interface. But the BlackBerry UIs are less attractive compared to Android UI. I want to make my BlackBerry UI more attractive like in Android.
#Dave Markle is right, this is a fairly general question. Assuming that by 'attractive' you mean 'UI Controls that look better than the default' then you'll have to do a lot of custom control work. More an more in the BlackBerry industry it seems that leading applications are doing almost entirely custom UIs.
I won't touch on specifics of graphic design, that seems outside the scope of SO, but a good place to start is to get a graphics designer to put together some conceptual screens, and then as a developer your job will be to build controls to match that.
There are some tutorials on the net about how to get started with that. I've written a few - "BlackBerry UI - A simple custom field" is a good basic introduction on how to make a custom control.
And a correction to #Dave's comment - you can antialias text on the BlackBerry - though it's not well documented. For example, a 9 pt subpixel antialiased bold font, derived from the default system font:
Font.getDefault().derive(Font.BOLD, 9 Ui.UNITS_pt, Font.ANTIALIAS_SUBPIXEL, 0);
Well, after a couple of beers a lot of things look more attractive... ;-)
But seriously, I think you're going to run into some fundamental limitations with the platform you have. The iPhone, Pre, and (I guess?) the Android all have dedicated graphics hardware which can antialias text and perform complex animations with relative ease. Most blackberries don't.
I generally suggest to people that when they do a design, that they try to stay within the boundaries of the device they're designing for. For example, if you're writing an app for Windows XP, don't try to make it look like it might on a Mac. Stay with the style of the best-of-breed applications on the particular platform you're designing for. Maybe this answer isn't helpful, I don't know... But it was a pretty general question.