Coming the grips with Android

2012 is the year that we’re going to include Android in the roster of solutions at Sobetech. I figured that with 15 years of Java experience, and understanding the mobile paradigm from learning iOS, that this wouldn’t be all that difficult to do.

This initial forays were very frustrating. There is something that you really don’t know and will really put you out when you come to Android from iOS. The iOS emulator/simulator can be started and stopped constantly. Many times, it just easier to run the test and turn off the emulator straight away. Trying this same kind of workflow in Android immediately made you think that Android is the worst thing ever invented. The emulator takes between forever and too damn long to start. Even with a reasonably powerful machine, the startup will sap almost all of the resources your machine can deliver. When first starting to work with a new language and/or platform, I tend to have to iterate very often.

I think you can see the conflict already. 30 minutes in shutdown/startup times per iteration makes thing simply untenable. Even worse was when I had to restart the entire machine because when trying to restart the virtual device wouldn’t work because it thought one was running, but it couldn’t be found. Now I keep the emulator running at all times like my email client. Shutting it down only when I am powering off the machine.

The next post will be about laying out a UI with as many files as possible…

A Festivus Miracle

In light of the upcoming App Store freeze, I was figuring that the update that I was pushing out at the end of the week would be lucky to make it through the review process in 2012. The order came through on Friday, so I worked non-stop to get the coding and testing done as soon as possible.

Luckily for me, the code in question was code that had already been done in other projects. This is where code reusability is paramount. I was able to get the coding done by the end of the day and the testing completed on Saturday. No issue in getting the binary sent to Apple and it was off to a good if shortened weekend.

This is where the miracle occurs. This afternoon, I get the push notification from Apple that the update is under review. WHAAAAAT!!! The first business day after a submission and it’s already under review. I’m starting to become very confused on the why’s and when’s on how Apple reviews iOS apps. Is there a secret to get the app to the front of the line? I wish it would be more like a deli. Get a number and see who is being currently being served.

But I’m going to accept my Festivus miracle. I’m happy and more importantly, another Sobetech client is happy.

Happy Holidays to all of you regardless of the holiday that you celebrate!

Still haven’t found what we’re looking for…

Once again, the failings of the internet browser raises it’s ugly head. We’re adding some additional reporting functionality to SobeCloud. This isn’t all that fancy, but just a table of data. The initial stages of development saw an initial HTML table. Simple and not all that hard to make. Then it was decided to take things up another level.

I’ve been working with HTML for the better part of 2 decades. I recalled how exciting it was when I was told about DisplayTags. Looking back, it was like being shown color TV after a lifetime of black & white. Thankfully, I hadn’t had to deal with tables in browsers much in the last few years. I was part of some architecture reviews where Flex, ES Table, and some other tables where being reviewed. They all seemed fine enough, but I was always concerned about how much of a pain it was to do something seemingly quite simple.

And once again disappointment sets in. Nothing has changed. If anything it has become worse. Previously your data was in basic forms. If the table library was pure JavaScript, then you just made sure to include the proper includes and calls, but the JSP in my case would be unaffected. If it was a Tag Library, just include the JAR and copy/paste into the JSP. Now you have to make JSON or XML and they just assume that you want to AJAX the hell out of this thing. Progress seems more and more like regression to me

The joys of marketing

While writing some marketing materials today, I reached a bit of a conundrum. How do you explain functionality that seems simple to you to potential customers? You’ve toiled for many hours to make something that you’ve thought about for seemingly countless hours, so you have a full grasp of the concepts. But your potential clients probably haven’t given it more than a fleeting fault.

What is a hard-core programmer to do? Ask people that like you and will take a few minutes to look at your materials. Make sure that they don’t have an idea of what an IDE does let alone what it means. Their 5 minutes will be worth more than hours of you re-editing the same document. But don’t take their responses personal. If they are true friends, they will be trying to help you. Their criticisms are ones that lost clients will never tell you. Take it to heart and get back to editing so you can focus on what you really enjoy. Development…

Reading the fine print

Rejection is never a good thing. Especially when you have to wait a week to hear it. I submitted the Sobetech Demonstrator Application only to have it rejected by Apple. The reason was something that confused me. Apparently an application that “focuses primarily on marketing or promoting your business” does not comply with the App Store submission guidelines.

That was a bit confusing to me. A majority of the applications out there that are tied to businesses seem to be some form of promotion. Maybe the data that I seeded in my application wasn’t robust enough. Has anyone else out there run into something like this?

Watch Your Bundle Version

I had been a bit inconsistent in what to use as my bundle version in my iOS builds. Sometimes I had used the same number as the version number. Sometimes, I would use the SVN version number that marked the deployment version. I think I even used the day of the year as a number on one build. I figured it was useful for some kind of housekeeping or accounting, I just didn’t know where or why it would come up.

Most of the applications that I develop do some form of communication with SobeCloud. So this week, I was looking on doing some much deeper reporting for our clients. That is where I found something quite curious. Previously, I was using the URL of the request to determine the application that was making the request. In some cases, where a newer version was looking in a version specific file, I would gleam that information from the URL. But if (and this is a real goal) the URL that different versions would look for was the same, I couldn’t really tell what version of the application was being looked for. But Apache access logs and iOS do give that to you. If you log the User Agent, you will see the application name as well as the bundle version. Very useful for reporting.

Storyboards

iOS 5 introduced an improvement in developing user interfaces in Xcode with storyboards. Usually IDE improvements don’t require a change in the language, but Storyboards is a pretty comprehensive upgrade to both the development environment as well as the language. The learning curve to storyboards was pretty shallow and that time spent was paid back in the time saved using storyboards.

Now enough of the Apple gushing and let’s talk about the pitfalls of going to Storyboards. There aren’t many, but you should know about them in advance. The first might be a corner case for some, but a major issue for others.

If your application utilizes iAD and table view controllers, you might have an issue. If you put the iAD banner in the table header, then you don’t have a problem. If your design was a view that contained a table view and the iAD banner above or below it, then you are screwed.The storyboard interface builder allows you to modify most everything, but if you try to adjust the hierarchy of the view / table view / table view cell in this version of Xcode, it just won’t run. You always have the option of bypassing the storyboard for this particular screen. Just be warned that going down that path can get you in some real troubles.

The next issue reminds me of a too much of good thing situation. As I started to really make a transition to storyboards I ended up with a file that looked like this:

At first, you might be quite happy to have a comprehensive view of your entire application. But since all a storyboard is an XML representation of a user interface, you will come to realize that even a powerful machine will be apt to beach ball on you quite often when you start trying to work with it.

Fortunately, there is a solution to this too. You can split your storyboards about into distinct functionality units. From there a call to the storyboardWithName:bundle: class method of the UIStoryboard class allows you an easy starting point to transition from one storyboard to another. A call to the instantiateInitialViewController method of this UIStoryboard object will get you the initial UIViewController of the child storyboard. If your application is universal, you do still have to go back to your old skills to determine the proper storyboard to load. Thankfully you only have to account for this in one place as opposed to every view controller in you application.

If you would like to know more about how to implement storyboards in your iOS development project, contact Sobetech on the menu above.