Posted by AVAI Mobile Developer on Tue, Nov 17, 2009 @ 11:25 PM
When developing mobile applications, user interface design is one of the most crucial elements that you need to worry about. Users are already restricted to a tiny keyboard and 3.5" screen, so they start out having less patience than they would for say, a desktop application. With that in mind, whenever an application has to perform a task that takes more than half a second, such as downloading data, or doing a lot of computation, the user needs to be notified with an activity indicator view or progress view that the app is still working, and has not simply frozen.
So how do we add an activity indicator to notify the user when the application is working? You might assume that you can add a UIActivityIndicator in Interface Builder, link it up with an outlet in your view controller, and just call the startAnimating and stopAnimating methods before and after the code for downloading images. With this method, the view will not actually be loaded on the screen until after the images are downloaded, so you will never even see the activity indicator. This is because the downloading of images is occurring in the main thread, which also happens to be the one used for UI updates. So, while fetching images, the UI thread is blocked from doing updates, so your activity indicator doesn't appear until it's done.
The solution is to download images in another thread, and call back the main thread when you're done. This can be done with the performSelectorInBackground and performSelectorOnMainThread methods from the NSObject class. The code below outlines the method just described.
- (void)viewDidLoad
{
[self.activityIndicator startAnimating];
[NSThread detachNewThreadSelector:@selector(downloadImages) toTarget:self withObject:nil];
[super viewDidLoad];
}
-(void) downloadImages
{
//Download images here
//Once the download is complete, go load the downloaded images into the table.
[self performSelectorOnMainThread:@selector(loadTable) withObject:nil waitUntilDone:NO];
}
-(void) loadTable
{
[self.activityIndicator stopAnimating];
[self.tableView reloadData];
}
Richard
Posted by AVAI Mobile Developer on Tue, Nov 10, 2009 @ 09:08 AM
I recently attempted to write my first Blackberry application. I knew that I would have to learn some new skills but, with my background in mobile development and my roots as a Java developer, I was up to the challenge.
I didn't start with anything too complicated. I found the tutorials section of Blackberry's developers site (http://na.blackberry.com/eng/developers/resources/tutorials.jsp#tab_tab_development) and started working my way through the getting started tutorials.
Now I've used the Eclipse IDE in the past, so I was ecstatic to learn that not only is there a Blackberry plug-in for Eclipse, but it's the recommended approach. I also learned that the plug-in is not compatible with my Mac OS X. Now I wasn't excited about this, but I can adapt, so I hopped over to the Eclipse homepage to download the newest version and installed it in my Windows VM. After, not too much time I have Eclipse up and running and return to Blackberry to download the plug-in. They have an easy to use installer, so I download that, hit install and I'm ready to go. Of course, nothing can ever be that simple. The install doesn't take and I have no message explaining why. I double check the requirements only to realize that the newest version of Eclipse is not supported. I have to head back to Eclipse and download an older version. Great, I haven't even finished the setup, and I've already made a mistake. But a simple mix up over the wrong version isn't huge, and I have been assured that Blackberry development is easy, so I'm not giving up yet.
I must say after I installed the correct version of Eclipse and ran the Blackberry Plug-In installer one more time, the install went off without a hitch. I opened my brand new copy of Eclipse, create a workspace, create a new project, and there in front of me is the option to create a Blackberry project. Score! At this point, I must admit I am excited. I love Eclipse. I really do. And after all the time I've spent fighting XCode, I'm finally back to an IDE that doesn't fight me. From this point on the process seems very simple. I follow RIM's very understandable Writing Your First Blackberry Application tutorial. The code makes sense, the RIM libraries appear easy to use, and within an hour I've written a very basic "Hello World" app. Now granted Blackberry has an unfair advantage over iPhone in this respect. When I wrote my first iPhone application I had never seen Objective C code before and the syntax was completely different than anything I had ever written before. However, I did appreciate that Blackberry development allowed me to use both a language and an IDE I was already familiar with.
Running the application in the simulator also seemed quite easy. Aside from the fact that it didn't automatically launch my application as the iPhone simulator does, the simulator seemed relatively easy to use with enough options to test various states my real Blackberry phone could be in while running an application.
With the great success I had had writing, compiling, and running my app in the Simulator I was ready to see it on a phone. This was the step I had most anticipated, not only because it always feels great to see my application in its final state, but because I had heard that putting an application on the Blackberry is a much easier process than putting an application on the iPhone. I still get a sour taste in my mouth when I think back to the struggles I had with my first several iPhone apps and making sure my code signing settings were just right and all my certificates in place and never being exactly sure what was wrong when XCode gave me one more cryptic error each time it failed to put the app on my phone. But this was not going to be a problem on the Blackberry. I connect my Blackberry and begin looking for the "Build to device" option. I can't find one. I return to my tutorial. Surely the tutorial's writer anticipated that the next logical step any developer would want to take would be to put their application on an actual Blackberry device. I scroll to the bottom, but all I see are suggestions as to other things I can add to my application and instructions on how to exit Eclipse. Thanks RIM.
I scan through Blackberry's list of tutorials and find one entitled "How to Deploy and Distribute Applications." Surely this must be it. Again I find another series of useful steps explaining how to deploy my application through the Desktop Manager. Great. I install the Desktop Manager update to the latest version, follow all the appropriate steps and I'm ready to go and I get an error when I attempt to install the app. I double check everything, make a few changes, try again, this time a different error. I try several different configurations, nothing seems to work. After several attempts, I resolve to give up on the Desktop Manager. Reading through the rest of the document I discover the javaloader deployment method. Apparently, the Blackberry JDE comes bundled with this easy to use command prompt tool. A simple call to "javaloader -u load yourfilename.cod", and my program is loaded on the phone! I find my application in the Downloads section (like the Simulator, it doesn't seem to automatically run it) and soon I'm staring at the familiar "Hello World" screen.
All in all, I must say Blackberry development was only a little more complicated than I anticipated. At the time I remember cursing Blackberry and complaining that this was not in any way easier than beginning iPhone development, but looking back, I can see that Blackberry development does have its advantages. From my limited experience with the platform I can already begin to see that it is well thought out and I'm eager to learn more. I won't say my first Blackberry app was easier or harder than my first iPhone app, but it was different. But different is good. While Blackberry and iPhone are both smart phones, they are very different, and they both deserve my share of respect as a developer.
Posted by Eric Mills on Mon, Jul 06, 2009 @ 09:55 PM
After hearing another horror story from a customer who came to us after a bad experience with another iPhone App Developer, I felt the need to offer up some advice on how to avoid a failed project. Here is the golden rule: Do not start coding until the app has been completely designed. Build the user interface and work backward. Don't even talk to any programmers for a few weeks during design. Don't just pencil and paper or whiteboard the user interface. Build the final user interface and use that as an asset to convey the scope of the project to the programmers. Once the user interface is exactly like you want it, only then should you consider writing code.
See, the amazing thing about a user interface is that everybody has an opinion about it. Nobody (except the programmer) is going to be worrying about what internal data structures are used, but every person involved in the app planning process will have "valuable input" on the layout and colors of the user interface. Get all of this controversy out of the way before engaging a programmer. Programmers hate redoing work because of user interface changes. It sucks the life out of them. A programmer wants to know the technical requirements of the project and be left alone to create the most efficient solution to the problem at hand.
At the end of the design process, create a design document. This is the single system of record for what is going to be created. this doesn't need to be a tome of formal terms that nobody will ever read. The design document should contain the following information:
- The goal of the application: Are we trying to create a fun game of solitaire, an ebook reader, or a mapping application? Should the main focus be on usability, speed of use, speed of development, or performance?
- All final user interface screen with descriptions. Don't skimp on the descriptions. Describe any non-trivial function of the app.
- Functional specification: This needs to be nothing more than an outline of the app and what every button and control should do.
- Schedule: How long should the development effort take? Ask the programmers, don't tell them. You convincing them it won't take that long will not reduce development time.
- How much will it cost? Translate the hours to dollars.
- Acceptance: A simple signature for client and developer to sign indicating acceptance of the design, schedule, and associated price.
This may sound like a lot of work, but once you start doing things this way, you will wonder how you ever got along without it. Get everybody on the same page from the beginning. Manage expectations through out this process and your app will succeed. Don't be lazy. Do this work and you won't regret it.