Using the iPhone for programming

I have been using my iPhone like a computer for some time now. The primary thing I do with my computer is programming. I dislike laptops and more dislike carrying around one. Over about 2 months ago - I experimented using the iPad as my primary go to computer. With the multitasking enhancements introduced in iOS 11, I could pretty much use it as a primary computer with a number work apps installed: Terminus (for ssh to development Linux server), Pythonista (for a fantastic on device python interpreter with a number of libraries I use - numpy to be specific, Working Copy (for managing git repositories), Textastic (the most fantastic source code editor for iOS). With these apps in place my next quest was to see if I could manage even without the iPad around. This is my week 2 of the experiment and I think I haven’t faced a lot of issue for on the go programming. These tools just work great for me. Now I can pretty much keep my laptop at home and use the desktop at work, while on the move I just use my phone. There are a few things like join.me and teamviewer that may just work better on a bigger screen, but then I can also connect my phone using the lightning to vga dongle that I sometimes carry - if there is really this need. 

Oh - and did I tell you that I wrote this post on the same phone ;) 

Peace. 

Printing on a white label BLE thermal printer from iOS - a quick story

Over at OneGreenDiary.com, we are building tools to help small merchants better connect with their customers. Check OneGreenDiary.com to see what we do, and do not forget to watch that video, we are sure you would love it :-)

While one of the core principles at OneGreenDiary is to be as paper less as possible, there are still places where a printed paper bill may be required. We avoided print support for our merchant apps, till one of our early adopters specifically asked for it. Since we are kind of cash strapped, and can not afford to spend on a damn printer that is iOS certified, we went over to alibaba.com and ordered this cheap Bluetooth enabled thermal printer that claimed to work with iOS : http://tousei.en.alibaba.com/product/60371489659-802143527/TS_M230_mini_bluetooth_portable_handheld_receipt_bill_printer_for_android_ios_mobile_58mm.html

Great. After the printer arrived, we though that it would magically connect to out iOS device and we did start printing instantly. Bummer. Ok, how about Android ? No luck. Apparently neither iOS nor Android provide native support for BLE printers. I tried to install the outdated Windows driver, and Linux cups drivers with no luck. Not even able to print on desktop. 

But then, Abhay C, a wanderer with us, found an iOS app called printer-x, that was a demo app to print on bluetooth enabled thermal printers. He printed this:  "hello, world!"

At this point we knew, it could be done. But how? All communications with the vendor didn't go anywhere. They send some sample iOS (Objective C) code, and some Android code, both of which didn't compile, and neither we could understand what was going on in the code. There were a few comments in Chinese that tried to be helpful. Chinese, not Swift. The programmers manual that came with printer reminded me of good old DOS assembly days. There was something, but didn't know where to start.

Next we tried to venture into programming our own BLE layer for printer communication. Instead of using the CoreBluetooth library we zeroed in on using BluetoothKit, which is Swift wrapper over CoreBluetooth library (https://github.com/rasmusth/BluetoothKit). So basically it is this: BLE frameworks try to give you two interfaces: Peripherals and Central. Peripheral refers to a device which can be discovered, asked for data, or can receive data. Central on the other hand scans for Peripherals, discovers characteristics offered by Peripheral, receive / send data to the Peripheral. One of the important thing to enable discovery is the UUID of the Bluetooth device, this can be easily obtained by using a discovery code, or a number of BLE query apps available on the App store/ Play store. I used the LightBlue app from the App store for this purpose. Once this device was discovered, we needed to connect to the device. The BluetoothKit provides a elegant interface to connect. But the issue started after this: apparently BluetoothKit's connect call back returns an instance of BKRemotePeripheral class, and this class exposes API to only receive data, not send! Apparently the class was more designed for bluetooth sensors, that only transmit data, not receive anything. Digging into the BKRemotePeripheral class, I found out a way to expose the embedded CBPeripheral object along with capturing CBCharasteristic objects. These are the objects of CoreBluetooth iOS library that allow lower level controls.

Next is when the DOS assembly like programmer's manual, which came with the printer, came up for help. After this I could easily figure out the code to issue a line feed to the printer device:

	let lineFeed = self.hexToNSData("0A")
	let printer = self.connectedDevice!.getPeripheral()!
	printer.writeValue(lineFeed, forCharacteristic: self.connectedDevice!.getCharacteristic()!, type: CBCharacteristicWriteType.WithResponse)

At this point, I knew, things were pretty much in control. The above code basically writes the hex code "0A" to the discovered characteristic. This initiates a line feed operation on the printer. Once this is done, it was a wow moment to print this:

and then this:

Since all of this code (written in Swift) was majorly based on BluetoothKit, we felt it was best to open up this part of the code, which is now hosted on GitHub: https://github.com/tovganesh/bleprinter-ios

Hope this is of some help, especially if you are trying to programatically access these kind of printers with iOS.

Note: Before you ask, I am still connected with VLife for all official (and practical) purposes. Once an officer at immigration and citizenship department in Oz told me, it is always good to be in love with two countries, you are contributing to both with your heart. Fits well here. 

Social Bus Spotter update

The Social Bus Spotter app (for Android), has got an update. The new features include:

- Real time position update of commuter (you!)

- Auto update bus position for next 5 - 30 minutes, once recorded.

With this, the commuter position is updated when using the app automatically in real time. Further, you can auto check in the bus position you are travelling in for a scheduled time span (up to a maximum of 30 minutes). The auto check in (update) to the bus position you are travelling in is useful to give a live feed of the bus. You can download the latest version from Google Play Store (https://play.google.com/store/apps/details?id=com.busspotter).

Social Bus Spotter app is now also a Web App accessible via. http://bus.savarinow.in

With this you can now access the Web App from any modern mobile browser - iOS / Windows Phone / Firefox OS / Android, are tested and works -. The Web App is simple and has limited functionality compared to the Android app. However, the basic functionality of viewing and making bus checkins are available.

OS X Yosemite : it has got really more advanced than Windows

I love staying up late to watch the tech events live. And the latest one is that of Apple: the yearly WWDC.

Of all the presentations I watched this year, the one by Apple yesterday was simply in a whole new league. It was pretty long, but not a bit boring. In fact it was more entertaining than a long spidy movie I had watched recently. It was that good. The best part of the presentation for me was the continuity feature demonstration on OX Yosemite and iOS 8. People who remember the Nokia Symbian may say that similar phone and message integration was provided on Windows back in 2006. That is true, idea is not new, but Apple has nailed the implementation ( search for my own app, btsms, to see how arcane was this back then, and then have a look at the Apple implementation - similar idea, miles apart in implementation ). But that is what Apple does, and known to do it extremely well, so well that all the 'credit' goes to them for inventing something that was already there. OK not really. But you get the point. Others are simply not able to take an idea and execute it in the best possible way, the Apple way.

After the demo by Craig Federighi, I can safely say that Yosemite blows Windows 8 in terms of usability, to the level that I am seriously thinking of shifting my home PC to a Mac (already use a Mac at office). By focusing on touch screens, Microsoft has lost all the time and energy to bring real usability to it's desktop. The thing is so bad right now that your desktop apps are called legacy apps. And that too when they are the most usable and productive of the apps. By focusing on touch first in Windows, Microsoft brought down the learning curve for a new user, but completely alienated an experienced and power user.

With continuity, Apple has shown how desktop and the mobile device can work in harmony, something that Microsoft has been trying to do, but never made it (may be 8.1 fixes some issues and probably 9 will be a lot better, but then precious time was lost). OSX usability does not stop at this feature, it goes on to everything from spotlight search to notifications to improvements in the mail and photos apps, all of which are simply quite superior to what is there on Windows 8.

The story on the developer side is an equal mess for Windows, but seems to be  quite a harmony for OSX and iOS. And with the introduction of a new programming language, Swift, Apple has not only made programming a joy for existing developers, but is sure to attract a lot of new learners to the platform.

PS :

// has become hit, I think it will over take printf("Hello, world!"); -)

This year : an experiment with an iOS device

I have used a number of iOS devices, but have never owned one, and never used one on a daily basis.

Enter iPod touch 5g (16gb model).




Lumia 800 and iPod Touch: going to use both on daily basis.

Now along with my two year old Lumia 800, the iPod will be my companion daily driver device. Being only 86 grams this is a sweet little pocket friendly device and compliments my Lumia in every way.

Let us see how this combination goes :)
 

Kosh: Building a mobile user experience for myself ;-) - I

I have been a smartphone user ever since I went mobile, my first phone being a Symbian Phone. Since then I have, on daily basis used newer version of Symbian, Android (up till Gingerbread), and now I am loving the beauty and elegance of Windows Phone 7 (Mango) on my Lumia 800. Intermittently, I have also dabbled with iOS and Bada. None, however come close to the usability that Windows Phone currently provides. For those of you, who still don't 'get' the Metro UI, this post might enlighten a bit: http://spillwaybrain.wordpress.com/2011/11/10/why-windows/
My primary requirement from a Smartphone has been programmability, preferably on the phone itself. With Symbian, I really enjoyed the pys60 (http://sites.google.com/site/tovganesh/s60) and now with Windows Phone, I am having fun with TouchDevelop (https://www.touchdevelop.com/wblh), more on this in subsequent posts. With Android though, I just couldn’t get connected the same way.
While Windows Phone is a great OS, the current price point makes it unaffordable to large section of people. This may change over time, particularly in combination with Nokia. On the other hand, Samsung, with its Bada OS, plans to build a ‘smartphone for everyone’. However, with the current programming model for Bada, particularly the use of C++; doesn’t really go well with the philosophy. Because, to me a smartphone should not only be programmable by a professional third party, but also as easily by the owner of the device; just as is the case with the PC. When you have this joy of programming your own device, you kind of connect to the device for a long attachment, not just for period of your current contract (anyone remembers the BBC Micro?).

The Phone
Most smartphone designs today seem to forget that it is actually a phone. So making a phone call on a smartphone is typically much slower than on a very basic Nokia device. You can't just start keying in the number to give a call. You have to open the Phone App and then give a call. And in some designs you even have to press one extra button to bring up the dialer app! Oops that is a complicated phone, but we still like to call it smartphone, for some reason.
So the smartness comes from the fact that it is able to do a whole lot of other things than just being a phone, not that it is easier to make a phone call from it. It serves as a communication hub. It basically tries to provide a complete mobile computing experience in your pocket. Over time, probably we will use the phone component in it a lot lesser, and then it would be more technical to call it a smartmobile.
Another drawback of most smartphones today is the battery life: it is simply unacceptable. Though my current Nokia Lumia 800 easily lasts for a day and half of normal usage (always on data, few calls and text messages, occasional games, about half hour of GPS usage - for sports tracker), for it to be usable by a large majority of people in a nation like India, it needs to run on solar power or an alternate form of energy (body energy, crank shaft, anybody?). Currently, though I can see Solar energy as the only viable solution. This could be coupled with a crank shaft enabled charger, though my experience with a crank shaft device (Philips radio), has not been that great : probably it had a design flaw.  For most of the mobile devices today, the display is one of the components that consumes the maximum amount of power. Without the display these devices could go on easily for more than a week. Take for instance the Kindle, it can easily go for about 10 or more days, even with the 3G radio on; with the radio off it lasts for more than a month. The one major difference is the screen: e-ink. Although the e-ink looks fine for a book reader, for a mobile device it will not work out. Options would be to use color e-ink or PixelQi screen. The recent demonstration by the OLPC project [http://www.youtube.com/watch?v=ITHNbOrPQyM] shows some hope, but a lot of work needs to be done to make it to a device that can be held in your hands.
To design the right hardware would be a challenge. At this moment I am not very clear about what this hardware would be, so I will use followup posts to put in my thoughts on the hardware side.

The UI
So, I want a smartmobile, whose primary functions is to stay connected with the people you care about: friends, family and co-workers. The Metro UI, which I pretty much like, tries to do this with what is called as a People's Hub. This is a well though out piece of UI, which threads all your contacts, communication into a single place. This also connects to the social media, and brings up the latest updates of your friends.
Taking cue from this, and observing how I use my mobile device, I think there are three most important things I do with a mobile device: Keep in touch with people, Search for information and use Applications.

So let me introduce to you : Kosh (Sanskrit: a collection / repository)
It is a collection of things I do:

• People Kosh : The collection of all tools allowing one to connect to people. The Kosh UI is always accessible from anywhere (if using a full screen application), by using a Swipe down gesture. People Kosh needs only three main components: Phone (which includes VOIP / video calls), Message (which includes SMS and Email) and Social updates (a quick way to be in touch with people on your social networks). The Phone and Message Apps are also 'live tiles'. Unlike Windows Phone 7, they will display additional information, such as from whom you missed the last call, last line from the text message you received recently etc.

• Search Kosh: The collection of all search tools. This will be central place to search anything (well probably some things in life are still better searched on your own ;) ) : either on the phone, or the Internet. The search can be either text based [input: on-screen keyboard], voice based [input: microphone, audio file] (this will not be just voice recognition, but should be localized, and probably should integrate music search, radio search etc.) and visual [image, camera] (scan image, photo, QR code, bar code and probably video clip).

• Apps Kosh: The collection of all apps. Device status like remaining battery, Network connectivity are just another apps. One need not have integrated UI for the same. Each icon acts as a means to launch the application. By default the icons are alphabetically organized (as grid of or as a list). Application icons may display notifications. Notifications can be in the form of text or image or a combination of the two, and are displayed alternatively or along with the default icon. Icons with notifications automatically move up and have a glow surrounding them. Once the user taps the apps with notification to open, the icons are automatically placed in their usual location.
  To switch between Apps, use three finger pinch. This will show a list of 'active apps' with end of the list being signified by a shadow on the edge. An active app is not the same as a background app : in fact, on a constrained device it would not be really a good idea. An active app here, is the one that has registered to the system for a background notification. Alternatively the only app that is available 'in memory' is the foreground application. The applications that require background processing (play music, for instance) will be handled by a system process instead.

The Architecture
Well, I want to build the full stack. That is because whatever is currently available is probably not going to work for me. It is not only important to get the kernel done right, but also the rest of the components done well to make for a great user experience (UE). The diagram below shows the most important components of this stack.

The Kosh system will be build on a mirco-kernel architecture. This would mean the Linux (or Android / Palm OS ) kernel would not be a good starting point. A QNX like kernel would be the way to go. The other components are the telephony and network layer, specifically for handling the communication needs. The system process for notification and other management purposes. The Kosh API layer for providing APIs for the UI layer as well as writing third party applications.

The Kosh API layer will have the above major components. I think for all that I outlined about, these set of broad APIs would be just enogh to start with. The UI layer will be build using these APIs and a WebKit based (or WebKit like) rendering engine. This essentially means all user interface layer will be build on HTML 5+ and JavaScript. Consequently, the Kosh APIs will be exposed as JavaScript. Also all the third party apps will be written using HTML and JavaScript. This is a philosophy quite akin to webOS. Essentially this means that EnyoJS might be a good starting point for looking at API design. Another project to look at is Mozzila B2G, the  Boot to Gecko initiative.

A carrier independent network
We are over reliant on the 'carrier network' for all the communication today. Though 'carrier networks' will not disappear overnight, it would be good to have a way of communication that does not rely on a centralizer carrier.That would allow for a medium of communication which is not overlay regulated. For emergency needs though, a carrier or satellite based solution is still required. Irrespective of this, for me, communication among humans should ideally be free, that is what takes the race ahead. At the moment though this is not exactly the case. There is the Internet, that was supposed to be a free medium, but due to one component: the DNS, it could be unfairly controlled. TCP does allow peer-to-peer communication, with no centralized control, but again for people to 'find' each other, we need a kind of directory service. Skype for instance uses peer-to-peer communication, but requires a central authenticating authority. A few years ago, Nokia, experimented with peer-to-peer, proximity communication, using an application called Sensor. The Sensor application (still available for old Symbian), used the Bluetooth as a means of communicating with people in proximity (instead of directly talking to each other!). The Sensor app would host a mobile page of you (like your facebook page), people could see this from their apps and if they like, send message to you, and probably become friends. Sounded like a pretty good idea, but somehow did not catchup, and the project seems to be abandoned altogether, at least for now.

I think, at least for local communication needs, one can setup a peer-to-peer communication system that is independent of any infrastructure. Every device in this system behaves as a carrier. Consider that everyone owns such a device. Also, in a modern city, I think it would be safe to assume that every person will find at least another person with in 10 meters radius (this is just a hypothesis right now, a proof for this would be amazing). All the devices in this system will have a unique number, and will be owned by a person. Every device will have a public and private key for the purpose of security. Now consider that a person wants to send a message to his mate. The way this would work out is as follows:

• The sender knows the public key and the device identifier of the receiver. For this to happen, both the sender and receiver should have met physically and exchanged this information once.
• A message packet is prepared with the device identifier, and the content encrypted using public key.
• In addition, the message packet will contain a field for signifying the importance along with a hop counter. At the source, the importance field will have the highest value, while the hop counter will be zero. Every second hop a packet makes the importance is decremented by one, where as the hop counter is incremented with each hop.
• The message is then broadcasted to all the nearby (say with in 10 meters radius) devices.
• If any of these devices is the intended device, the process completes. There still might be lingering packets in the network carrying the original message, these will eventually die as their importance decreases.
• If the importance field of the message packet reaches a negative value, it is not re-broadcasted, else it is re-broadcasted.

The above is quite akin to the way messages were transmitted in olden days (that were not from Kings). I think this should work wonderfully if the density of the device is sufficient, though at this point I don't have a proof of what this sufficient number should be.
One drawback of this system is power requirement. I am not sure a device that would handle this amount of traffic can last for long, given today's battery technology: the radio (apart from the display) is a major power guzzler.

Alternative positioning
While the GPS works great where I live, and I am actually pleasantly surprised by the accuracy of Nokia Drive app on my Lumia, there is a need for a cheaper solution that will work even if the satellites are out of visibility. Nokia Lumia and most other modern smartphones supports A-GPS, which augments the satellite positioning with other information such as cellular tower positions, wifi hotspots and the IP address of your device to give pretty accurate positioning information.
Another approach would be to use landmarks as a way of positioning. This would basically involve the use camera and some image processing. The device will store information on the known landmarks and their positions. The stream shot coming from the camera will be mapped on to the available landmarks and approximate position calculated. A system like thing, might not be good for turn-by-turn navigation, but will be useful if your are walking or cycling and you want to roughly know your current location. Again, this is not a substitute for GPS, which also provides altitude information, but then for day-to-day use this might just work out.

Programming Model and On-device programming
Kosh will be using HTML + JavaScript for user level programs. Any hardware level code will be written using pure C.
The most challenging aspect, though is to create an On-device programming environment that is easy to use, but also powerful to take full advantage of the capabilities of the device. In my earlier post on Nokia Lumia, I had mentioned about TouchDevelop from Microsoft Research. This is terrific on-device programming environment and I have not found anything yet that comes even close to this. This is one environment that makes me love the Lumia (to see stuff I am up to using TouchDevelop, visit: https://www.touchdevelop.com/wblh). 
To make Kosh really interesting an on-device programming environment akin to TouchDevelop must be built.


References
[1] http://spillwaybrain.wordpress.com/2011/11/10/why-windows/
[2] http://enyojs.com/
[3] http://www.eink.com/display_products_triton.html
[4] http://www.pixelqi.com/products
[5] http://www.qnx.com/products/neutrino-rtos/index.html
[6] http://www.webkit.org/
[7] Wiki on Nokia Sensor: http://en.wikipedia.org/wiki/Nokia_Sensor
[8] Mozilla Mobile web OS: https://wiki.mozilla.org/B2G

Followup
At this point, I only have idea. Not a single line of code to show. But to start it up, I had to write this down. This is just a beginning of the things to come, and hopefully you will love it too :)

Fine Print
The ideas, text and graphics in this post are exclusively created and owned by the author. The templates for few icons in the post are taken from a Google image search, they were then suitably modified for my needs. All the above content, and any followup posts with the label "kosh" is henceforth made available under Creative Commons License (http://creativecommons.org/licenses/by/3.0/) and may be attributed as : Kosh, by V. Ganesh.
The text also contains references to product names, and are trademarks of respective organizations. They are used in the text for information purpose only.