Recently, I was working on an app with Xamarin where I had a long list of colors that the user can pick from. I created a Simple ListView inside my app to display all of the colors in a table. However, this approach presented some unexpected problems such as:
How do I display a preview of the color next to the text label in my ListView Cell?
How do I keep track of what colors are selected by the user?
How to display a checkbox next to a color once it’s selected?
Over the last couple of weeks, I have made great progress on two apps that I’m writing. Working on these two projects every week has been a personal goal of mine since I started this blog, and I’m excited to see what the future holds. However, this progress means that the development process starts to slow down and the testing phase begins. This past weekend, I spent most of my time getting ready to move my apps into testing mode. During this time, I developed some tips in order to help newer developers get ready for testing.
If your new to mobile application development, one topic you should learn early on, is the concept of threading. Threading is a computer science term that handles the order of execution of tasks on the CPU. Threads are usually handled by the operating system. However there might be some tasks that can only be carried out on specialized threads created by the OS. To put things in context, consider the following example. Lets say I create an iOS application that uses a REST API to fetch data about upcoming concerts using location data. When you launch this application, the app freezes, takes a long time to load, and you see a white screen for more than 3 seconds. This is a common example of an app thats not optimized for the use of threads. As a result, you might receive complaints from your users saying that the app is slow or they delete your application all together. After a while, you decide to make some changes.
Upon inspection of your code, you find that your REST call is causing this slow down inside the ViewDidLoad method. you have to remember that in this case your code is being executed line by line. This means when your REST call is carried out, the CPU must finish getting your data before displaying it on screen. After reading this, you may be asking why does this happen? This happens because by default your application business logic and UI are loaded on the same thread called the main thread. Quick operations like simple math and string manipulation are perfectly fine on the main thread, but time consuming tasks like REST calls are not the best option. So how do we fix this? The simplest thing we could do is move this time consuming task to what is called the Background Thread. The Background Thread is a thread designed for complex operations. In return you leave the Main Thread open for UI changes. Here is some example code on how to make this happen.
If your reading this, then you stumbled on to my next post since writing my introductory post on New Years Day. If you have not read that yet, I strongly suggest you do that to learn more about why I’m blogging. Anyway, today’s post is all about some recent findings I discovered during the development process of the ParkLane iOS app. My use case is pretty simple and common for the platform. I have a login and sign up ViewControllers inside my app where the user can fill out some fields to create an account in our database or login into a existing one. However, I needed some kind of alert to pop up on the screen to tell a user if one of the following errors occurred:
Wrong Email
Wrong Password
Wrong Email and Password
As you can tell this presents a problem. I know Apple has something to solve this called a UIAlertView. Its pretty simple to use, it looks like this: let button2Alert: UIAlertView = UIAlertView(title: "Title", message: "message", delegate: self, cancelButtonTitle: "Ok", otherButtonTitles: nil)
// show alert on screen button2Alert.show()
I wasn’t worried to use this code because I’ve used it before, However Xcode presented me with this warning:
UIAlertView is deprecated. Use UIAlertController with a preferredStyle of UIAlertControllerStyleAlert instead
This left me puzzled, after doing some research this change occurred around the release of iOS 8 in 2014. After thinking about it some more, It must have been a change that I simply missed, and I take the blame for it. In a request to redeem myself I took out the old UIAlert code and replaced it with the newer UIAlertController.
After trying this new API, I have to say I like this better than the old UIAlertView. The newer framework seems like more work, but your getting more control over your alerts. Here is a quick code example to show you the difference.
If your familiar with how iOS views work the this seems pretty straight forward. I bet developers that don’t understand iOS or Swift can figure out what this code does. I also enjoy that the addAction method has a completion handler in order to execute some custom code when you tap a button on the alert.
Before I go, I realize that this first iOS post was pretty simple but do not worry. I have plenty of content coming up on more advance topics. So keep following my blog and be sure to follow me on Twitter to be alerted when new content is posted.
iOS Development 
