Reading time : Less than 30 minutes
Its been a while since I touched this blog, apologies first. And this is my third (perhaps fourth) mobile platform article in this blog. I have touched the following in the past,
And today, it is going to be iOS. The reason why it took a decade to touch the iPhone platform is that, the development tools offered by the parent company, that is Apple, is not so much cross platform. You need a Mac and a iDevice to develop applications for this platform. And of course, it is going to cost you a fortune. A proper Macbook Pro (ME866HN/A) and an iPhone 4S eaten up around $2800 from my wallet. But on the flip side of that, it is a good investment to make, at this point of time. Apart from the opportunity to build iOS applications, it gives you a very good laptop and a smartphone. Lets get to the actual topic now.
Apple did a wonderful job developing and packing a very good development tool called Xcode into a single unit. For those who come from other mobile platforms and IDEs, they are gonna feel like in heaven. Xcode can be used to develop apps for both the mac as well as the iOS. It also includes all the documentation required for both and all the device simulators like iPhone and iPad. So, it is a rugged, one click installation package, which brings you everything, to get started with the actual development.
Overview : What we are going to do in this post?
Create a New Project
Launch Xcode. It will be in your Applications folder if you have installed it from the App Store. And select Create New Xcode Project from the welcome screen. Xcode will now greet you with a template selection dialog. Obviously, select iOS > Application from the left pane, and select Single View Application, and press Next. This next window may seem a bit of overkill, so just fill it with what you see below.
Press Next and you will be asked where do you want to save your project to. Select some convenient location and press Save. You project will be presented as the following in the Xcode main window.
I’m not going into a lot about Xcode, you may find tons of info about it on the web. The left pane is the navigation pane, where you can select a file or resource from the project and the centre pane will be presenting you with the contents of the same. And you will find a very interesting file named Main.storyboard. In layman terms, this file contains the user interface for the application you intent to build. iOS architecture is MVC complaint, and the VC (View and Controller) part of it belongs to the storyboard file. Every screen in your application is roughly a view controller. And the transition between screens is generally called a segue.
Building a Small Calculator Application
When you click on the storyboard file, you will be presented with the visual user interface editor in the centre pane. And the right pane is split into two halves. The bottom half is called the library. You will see a small cube icon there, which is the object library, form where you can drag and drop UI elements into your storyboard. For building a calculator application, we need two text boxes and four buttons for representing each of the four arithmetic operations. Here is the UI I have built with my storyboard.
On the left, I have one label to display results as well (the text in it is set to 0.00 initially). You can adjust properties related to a particular UI element from the top half of the right pane. Select the text boxes one by one, and change Keyboard type from Default to Number Pad. Guess why we do this! :) It is worth the time to get yourself familiar with different tabs and panes in the Xcode application.
Now we have all the required UI, and what left is the code which drives the UI to derive the expected result. The coding part is not marly coding in Xcode. What we need from the UI is the actions, such as the button click for each of the buttons corresponds to each arithmetic operation. For doing that, we need to tap those events from our code. Since we have created a Single view application, there will be only one set of code files in our project folder. Which in my case ViewController.h and ViewController.m. There are another set of code files named AppDelegate.h and AppDelegate.m, which we don’t have to worry about, for now.
Discuss the Code
The linking of action from the UI to the code is an interesting task. As the first step, switch Xcode to the Assistant Editor mode. For doing this, click on the Assistant Editor button on the top right portion of the Xcode toolbar.
Now you have both the storyboard as well as ViewController.m visible in the centre pane. You will see two sections in the ViewController.m file. One is the @interface section and the other is @implemenation section. Now carefully select the first button from the storyboard, that is “Add”, and press control. Now keeping the control button pressed, drag it to the @implementation section in the ViewController.m file, and let go off the mouse. You will be presented with a small popup window that looks like what you see below. You might feel a bit strange doing this, or fail a couple of times doing this correctly, but this will feel quite comfortable after a while.
Enter the name for the function as addNumbers and press connect. You will see that a method stub appear in the ViewController.m file. Do the same for all the four buttons, resulting into four method stubs looks almost the same. My stub names are the following.
Now that we have all the action handlers. It is promised that when any of the four buttons are clicked, those events will be passed into these functions. But for doing the actual arithmetic operation, we need to read the values from the two text boxes we have. For doing that, we need references to the text boxes from the UI. Just as like we did for the buttons, click on each text boxes and Control+Drag it to the @interface section. Note that it is not the @implementation section like we did for buttons. Name each of the text boxes accordingly. Yet again, we also need references to the Result Label to print the results back to the UI. So Control+Drag the label to the @interface section as well. After dragging all three, my @interface section looks like the following.
@interface ViewController ()
@property (weak, nonatomic) IBOutlet UITextField *num_one;
@property (weak, nonatomic) IBOutlet UITextField *num_two;
@property (weak, nonatomic) IBOutlet UILabel *result_label;
Now, we are ready for coding. What we need to do is the following.
I have the complete code for your reference. Please note that, I have refactored it a little bit. I created a function which does all the arithmetic operations.
Running the Application on a Simulator
Now it is time to run the application. Press Command + R and Xcode will launch you an iPhone simulator by default. Here is the result screen.
Obviously, there will be an exception if you are trying perform a division, while the second number is zero. Exception handling and working with bugs in the application has a good deal of process to do with the inbuilt objective-C debugger, which is a very interesting topic. May be I can put up another post for that. This one is already getting too long
Thanks for reading // Happy hacking.
Reading time : Less than 30 minutes
Its been a while I was thinking to post an article about broadcast receivers. I have done a number of projects which makes extensive use of broadcast receivers. There are a number of use cases where broadcast receivers are highly usable as well. Lets see how broadcast receivers can be made use of in Android. In layman terms, broadcasts are like a message that is sent across the entire system. Anyone with the appropriate address and permission can read the broadcast-ed message. For the sake of simplicity, I’m dropping out the concept of permissions. Basically you can catch broadcasts using a Broadcast Receiver with correct address or action as called by Android guys :). The word address in the context of broadcast receivers refers to an Intent Filter, by means of which, anyone can receive broadcasts that comes under that filter. Lets start with Intent Filters. Intent Filters can be defined in your Android application in two ways.
Note, that you cannot typically use an Intent Filter defined in the manifest through any Java files or vice versa. Or atleast I don’t know if that is possible. Anyway, it is safe to say that, you can use Intent filters defined in your java files to create broadcast receivers that has an Activity scope, and you can use manifest based filters to create receivers that has the Application context. So it turns out that, you can create two types of broadcast receivers.
To enable a broadcast receiver, you need to register it per se. As explained above, you can register it for the entire application by registering it through the manifest file, or you can register it inside any activities you need to receive broadcasts. Before going into depths of the same, lets see how to send a simple broadcast.
Ok, there is a hell lot of variants for the broadcast sending function. For now, lets check out the simplest one, that is sendBroadcast(Intent intent). This method takes an intent as the parameter. Lets see how this can used in a typical condition.
This is simple huh? It sends a simple broadcast with an action string ACTION_HELLO as the so called address. This simply means that, any broadcast receiver with intent filter set to ACTION_HELLO can receive this broadcast. Lets create such a broadcast receiver.
Ok, it still doesn’t says what intent filter this receive is planning to use. So we have to enable or register this broadcast receiver to do that. As we have seen earlier, we can register it for the entire application or we can register it for just one activity. For registering it for the entire application, you need to add the corresponding entry into the manifest, inside the <application> tag.
And for doing the same inside an activity, you can do it simply as follows. Remember, this particular receiver will work only if the activity is visible and it cannot receive any broadcasts if the activity is not in the foreground.
Ok, this part needs a little bit of explanation. We may simply register this receiver in the onCreate() itself. But in that case, there is a risk of leaking memory if the activity is killed or has moved to the background. To avoid this, I register the receiver inside the onResume() and safely unregister the same from inside the onPause(). As you might know, onPause() will be triggered when the activity is about to go to the background. A complete sample project is available here for downloading and testing out broadcast receivers.
Reading Time : Less than 10 minutes
Lately I was onto more experiments with the 433Mhz serial communication modules. I have purchased two different pairs of 433 modules which is shown in the image below.
My initial plan was to use a pair of encoder and decoder from Holtek to connect the two end-points to peripherals. Infact, that is just a cost effective method to implement remote controlled applications such as car-locks or automatic-gates. Those ICs are indeed not very flexible in the sense that, if we want to connect a large number of devices through this channel, it is quite difficult. Holtek’s (en)decoders provides upto 12 bits to be transmitted over to the other end. Out of which atleast 8 bits are address bits, and the remaining can be used as data bits. Generally these ICs provides, 2^12 = 4096 devices to be linked through this channel. But the problem with this implementation is that, if all the 12 bits are used to address devices, then there is no room for sending the actual data. If we take N bits out of 12 for sending data, the number of devices that we can handle, shrinks to 2^(12-N). That is, suppose if we send 4 bits of data in every trigger, the number of devices we can handle at the same time is, as small as 256.
One way to get around this problem, when we use N bits for data, is to keep the address bits the same, and send the actual data in chunks of N bits. Say for example, suppose we have to send the following stream of bits to a remote device,
1010 1010 1000 0101 1110
Say we have N = 4, the idea is to send it as follows. Please notice that the first 8 bits are the address of this particular device.
This looks promising, but one question remains. How these chunks of data will be concatenated at the receiving end? So basically, it turns out that we need a Microcontroller for doing this. Well, then another question pops up, If we have a Microcontroller, then why should we use these limited 12-bit junk from Holtek?
This is exactly what I’m thinking right now. I have done some preliminary experiments with the 433Mhz modules and an Arduino here. Generally we can send square waves through these modules as it is. I have tried running the following simple sketch on it and I got the exact same signal on the other end,. It is worth noting that, there is some minor noise bursts observed in one receiver module’s output. No big deal, just a side note.
There is one more significant problem remaining here to be solved. When there is no signal available at the receiving end, the 433Mhz receiver produces garbage square wave. So, how do we find when to listen for the actual data and how it is interpreted? The simplest answer to this problem is that, We implement a protocol for it! Ok, we need a protocol to send the signal over to a device, so that it can identify actually when it receives a command and what exactly is the command it just received. I’m going through different serial protocols right now. I will surely pickup one of them, or in the worst case “invent” one of my own. Either way, I will post about it in the next article.