UITextField Change made by Apple

The following worked prior to Xcode 5 + iOS 6:

@property (weak, nonatomic) IBOutlet UITextField *source;

if (![self.source.text isEqualToString:@""])

It now needs to be

if (self.source.text != nil && ![self.source.text isEqualToString:@""]) {

Previously if the user never touched the text field you got back an empty string. Now you get back a nil string instead. 

Just found this while testing code I am updating for iOS 7 while running on a device under iOS 6.

Shown for simplicity. In the actual code I am using a utility method to trim the string and check for a length of 0. The stupid trim method for iOS is a super long line and can be found all over the web as everyone must write it over and over as Apple does not include it in the base NSString object.

Finally have new ActionBarActivity working with Android Studio

Yes I am a sucker for punishment. The new Android Studio 0.2.6 came out today and I found this out my usual way - saw it on Reddit. Since I just battled this beast yesterday I thought I would give it yet another shot.

Post install it still could not build my project but was mad about even more things. I decided to delete the entire project off disk and start fresh especially since it kept being mad about gradle build settings and make settings that I would change and save and it would forget I had done that.

I deleted the project. Started AS, told it to create a new project with old project name, single activity. While it did this it appeared to download some additional gradle files. Probably updating from 1.6 to 1.7 but I am not sure. It did not do that when opening my old project.

Shut down AS. Copied the java source code, resource files and manifest over from the working Eclipse project. I did not want to risk changes to a working project. Started up AS and it found all the files automatically. I love that about Java, just put the files in the proper directly and have at them.

Copy in the build.gradle from this web site http://www.recursiverobot.com/post/59267986367/setting-up-the-new-actionbarcompat-in-android-studio then add the dependencies to the two bonus libraries I am using - achartengine and GSON. Run the rebuild all and everything worked like a champ. No errors. I was able to deploy it to my Note II and it ran perfectly.

Obviously multiple things happened here. AS was upgraded and it needed to upgrade various support tools which it did not do until I forced it via creation of a new project. That is pretty annoying. Once that was in place it is finally working.

I am glad they fixed the issue dealing with Google support libraries. The actual editing you do to the build.gradle is simpler than the project import work I had to do in Eclipse. You can read those steps here http://developer.android.com/tools/support-library/setup.html

Do I think this project will keep working? Who knows, seems on the AS side of things they make changes that require you to start with a fresh project or you are hosed. Gradle is in flux too. I like the editor and layout preview features of AS so I may use it for the next parts of this project. I really want to come up with functional tablet layouts beyond what you can do on the phone. I have everything split into fragments so this should be possible. I also want to use more than just the pie chart from achartengine and have more than one chart on screen in tablet mode.

This ties back into the JavaScript work I was doing in another area of our product. While that works in the browser on tablets it is slow and cumbersome. I should be able to do something similar in native code with large gains in speed and usability.

Using Genymotion to test against various device sizes. Nice and fast and recommended when you are not testing on an actual device. Very happy they added device rotation support.

Converted from ActionBarSherlock to new Android compatibility library

Since I was never able to get ActionBarSherlock (ABS) to play nice with Android Studio (AS) I thought I would convert to the new blessed by Google Android Compatibility Library and the ActionBarActivity.

Of course that did not work out as planned. I finally gave up on AS and just got it working in Eclipse. I tweaked the code and add an action bar menu item, setup a new base class and did some code clean up. It all works great. I guess I need to try it all in AS again but it gets so frustrating. I really like IntelliJ and there are some cool features I am missing by sticking with Eclipse but AS just is not right in the head when it comes to working with 3rd party libraries you need to import as library projects.

Some are now saying "Yeah, the IDE will show an error but it will run on your device!" Look, I hate warnings in my code and tend to turn as many of them on as possible so the IDE catches as many stupid mistakes as it can. Now to have an outright error everytime I build? No thanks.

I do like the new compatibility library. Got rid of the word Sherlock from various areas in the code so it all looks more native and cleaner. I have missed working in Android land and with a little break in the action I have been able to sneak back in there to do some minor tweaks to our app.

My plan is to get it all working in Android Studio so I can use the best of both IDEs. Prior to ABS and now the compatibility library I was not having any issues doing that.

JavaScript and Highcharts

When you work at a smaller shop you get introduced to a lot of technology and you pretty much have to go with the flow. For the past couple of weeks that flow has been down the white rapids of JavaScript for me.

The goal of the project was conversion from flot to Highcharts. Flot offered some very basic graphing and they wanted more eye candy and functionality so they decided on Highcharts. Will cost the company a licensing fee but it will be a much more professional product in the end.

I have not done much JavaScript in the past. I know it is not Java but the syntax is very close so getting up to speed on that was not an issue. Figuring out all the nuances is another story. I have the project up and running now with some final polish so it works better on iPads and Android tablets.

This would be considered a small project. Single page with two tabs. The page contains a dashboard layout control and you can add widgets. Each widget has associated HTML, shared CSS and a JavaScript to query for the JSON data and convert it into Highchart format. We have all the fun of formatted tooltips and configuration settings such as legend position and visibility of data labels.

So where does the fun begin? The whole code / debug cycle is a bit frustrating. I am using Eclipse and Chrome. If I just change a JS file I can save it in Eclipse, hit refresh in Chrome and see the results. If I am changing CSS or HTML I get to clear the cache in Chrome then refresh to see the changes.

Chrome has a decent debugger but you have to make sure you include the JS in the proper file for Chrome to see it as a source file. I had to remove it from a styles.js and move it into a controlling HTML for this to work. Then the break point may or may not work. You end up doing console.log(object) and then just sniffing around in the output console to see what is happening.

Don't forget console.log('Widget is ' + widget); is totally different than console.log('Widget is'); console.log(widget); The first one converts widget to a string which is generally useless. The second set of lines will show widget as an object you can inspect.

JSON.stringify(object) can come in handy at times. You will get circular references for core objects but for looking at return values from the server and what not it works fine. I usually copy that output into Sublime Text 2 and run the JSON formatter on it to get a good look at the results.

Since JavaScript is not strongly typed Eclipse is not a lot of help when it comes to finding variables and methods. You just have to know what is there by opening code and looking around. Not the best way to be productive. You also are not told your code is crap until you run it. I know dynamic languages have their strong points but I really missed this area of strongly typed languages.

Scoping is another bit of fun. If you want to trigger an event from one place and catch it in another, well it works but figuring out the proper scope can be a bit of a pain. It is all up and running but I ended up getting a lot of help from a developer with a stronger JavaScript background than I. In the end I was still unsure why what he handed me worked but I was just happy it did.

Highcharts is a really solid product. I am very happy with its final look. I was able to pull off a number of cool features. I did a lot of web searching to find out how to format tooltips, grab events, set up gradients, use multiple y axis, do stacked bars, etc. It really helped to be able to run jsFiddle sample projects. Guess that is one of the nice things about JavaScript, you can piddle around with it on a webpage before you toss it into your project.

Trusting the API is not a good idea

You are programming right along and need to accomplish what appears to be a simple task. You look at the API used by the company and find a one line call to do what you need. Make the call, get the expected results and move on to the next task. All rainbows and unicorns right?

Not so fast there bucko! The key word here is fast. The method I called did do what it needed to do and returned nearly instantly because I hardly had any data in my test database. Once you had a large amount of data it was painfully slow as we found out when attempting to run it at a client site. I had no logging output around the call as it was never an issue for me. It just looked like the program froze when running at the client location.

When something breaks I blame myself. I figure it must be in my code. Took another developer looking over my shoulder to point out "That call might be slow". I had looked past that line over and over again. Of course when I ran the program it sailed right past that line so I never thought about it. I was blinded to it because I was sure I was the one to blame.

We were able to have the client run another command against the database to clear out some old data to get them past that point. We then found the next step, again relying on the API, was also very slow but I had logging in place to watch that progress.

Time to rethink how all of this needed to work. We fixed the initial call to work in a reasonable amount of time and are in the process of gutting the code to write records to a file which we will then import via "copy {tablename} from {outputfile}" x 4 instead of doing inserts in the code. We were able to import 1.2 million records in 1 minute and 46 seconds using the 3 copy calls where it was going to take days to do it in code one insert at a time while parsing JSON streams.

This particular client has a much larger dataset than any other client. We are talking to a 3rd party vendor to get the 8.2 million records that need to be inserted via JSON requests. After these code changes things will run faster and scale better for every client. My part of the code is the JSON to our database format conversion. So far that appears to be working properly at least.

I made the mistake of trusting the existing API calls. I have only been at the company for 4 months meaning I had no background in company lore. I had no ideas what areas had bitten folks in the behind in the past and I figured the every call was optimized. Trust no code especially "this one line can't do much or take long". I should have put logging messages above and below the API call so I could have spotted this in the client run quicker. We knew up front they had a ton of data. We knew we did not have a large sample for testing. This is where extra logging is really helpful.

Lesson learned. I hope I don't make it again.

When you know it can be done is coding is easier?

There are times when you are coding that you are not sure what you writing can be done. Oh, sure most anything can be done if you sit down and look at it logically and have enough hardware and time. What I mean is you have not seen it done before so it feels harder. It is easier to give up and work on something else.

But what if you have seen it done before? A really cool transition effect on a mobile device, a pop-up menu on a double tap of a row, fragments that work differently between a phone and a tablet in a unique manner, etc. You know it can be done, you have seen it running on similar hardware to what you have, now duplicating it is a challenge.

Same thing goes when you have written similar code in the past at maybe another job. You don't have access to that source code but you know you basically wrote the same thing before. Again you have a programming challenge instead of a "how the heck can this even be done" task.

I ran into this again today as I was converting code from straight activities to ActionBarSherlock fragments. Everything I was doing I had solved in some manner in the past. I totally knew it could be done so even when it was not working I knew it was because I had done something stupid. My frustration level was pretty low. I did get stuck on one issue but a lunch break and trying to word a question mentally for a web search triggered a new thought showing where I had messed up.

If you are writing a new piece of functionality and it is not working you are unsure if you totally screwed up or if there is a limitation of the SDK or language you are butting up against. Of course you don't want to blame yourself so you start looking for things that are wrong with the API especially if you are new to this framework. You tend to get frustrated quicker and the frustration will be deeper. "This just can't be done" you tell yourself. "There must be a bug in the SDK" rolls through your mind.

Grabbing at straws comes into play. Move it to another thread, yeah that's it. Change the order you call things, that'll fix it! Try a 3rd party API or another widget, the one I first picked must be a steaming pile even though it was the highest rated one on Stack Overflow. This stupid thing has got to work, ain't nobody got time for that.

Finally you solve the problem. Turns out you were at fault the whole time. You were on the right track but you thought the range was 1.0f to 0.0f when it was 0 to 100. You found an obscure post on the web and you spotted the author passing 75. The API is fine, in fact once you stopped cussing at it there are some really cool features it has that you hadn't gotten a chance to use yet.

Programming is a really weird occupation. You spend a good part of the day dealing with the unknown, trying to pull something off you think can happen but maybe can not. Some days you are writing code nearly from memory just humming right along. You have done something similar and this is nearly a no brainer. Just create some objects and parse some JSON, easy peasy.

Other days you are trying something totally new. You have to integrate a third party pie chart widget. You barely know where to start. You spend some time pouring over documentation so hopefully it works the first time. You find some example code and pull it off the web. Do you start a test app? Do you try to drop it into the existing app? Is all the example code in fragments and you are using activities? Can't I just find an exact example of what I am doing? Of course not, the chance of someone else doing the exact same thing you are doing is really low. Heck if everyone needed it then it probably resides in the base language, one of its core libraries or somewhere in the SDK.

The best we can do it post things we figured out to our blog or answering questions on blogs or Stack Overflow. Let others learn from our experiences. Coding should be about solving specific issues for a company not constantly reinventing everything. Grab as much code as you can from other projects you have done, other websites and the SDK itself.

Why I stopped using Android Studio - for now

I was pretty happy using Android Studio. Loved the way I could see the preview of a layout while working on the layout. I had written a new app from scratch to match the functionality of our current iPhone app using Android Studio. I also like the dark theme they provide. Easy on the eyes.

Then I ran into a problem that made me stop using it. I wanted the app to run on more devices so I turned towards ActionBarSherlock. I found various posts on Stack Overflow on how to make it work. I tried them all but was ending up with some weird gradle errors that I was unable to solve.

Gradle: A problem occurred configuring root project '{my project}'.
> Failed to notify project evaluation listener.
   > Main Manifest missing from /Users/kpeck/AndroidStudioProjects/{my project}/AndroidManifest.xml

I have a manifest file of course. It is not in the directory given. I even tried to copy my the file to that directory, even though it does not belong there, and attempted the build again but it still did not work.

It is possible that starting a project from scratch with ABS in it and then copying in my files may work. I will have to give that a shot at some point.

Having run ActionbarSherlock under Eclipse in the past I knew pretty much what to do and had it up and running in a matter of minutes. Import the project into the workspace, delete the duplicate android-support-v4.lib, set the dependency between ABS and my project and it was working. I spent the rest of the day converting code to ABS format. That was generally pretty easy with a few minor snags around loaders.

At some point I may go back and attempt to get it working in Android Studio but right now I need to move forward on the project. I have other areas that I want to convert to activities hosting fragments. Currently I only converted the one that needed a loader but I have some ideas on how to layout items on a tablet that would benefit from fragments.

Android Studio keeps changing the way you deal with project settings. It was through a dialog but now they want you to manually edit things in the build files. Somethings happen automatically as you import but it does not seem to finish the job. It is still alpha software and they are pushing out changes quite often. I want to get familiar with gradle but I don't have the time to pause right now and do that.

I also found the preview has some issues especially with Relative Layouts. The above / below / left / right layout parameters seem to be suggestions in the preview. They work fine in the emulator or on a device but that gets frustrating. I may see the screen look just right in the preview then a change to the XML in an area unassociated to the Relative Layout will cause it to paint incorrectly, usually overlapping controls. Really need a preview I can trust so I am not chasing down issues that don't exist.

Probably good to wait another release or two of Android Studio. There will be more tutorials on how to make things like ABS work with it and I can skip the headaches. Back to trusty old Eclipse for now. I found a dark theme that is reasonable for it but it only changes the editor pane. That is the largest part of the screen so it is better than nothing.