iPhone 4 home screen
Stelios tagged me so here is my iPhone 4 home screen. I am supposed to pass the torch to someone else, so my brother will take it from here.
Thursday, 18 November 2010 8:33 pm
Developing for Android and Windows Phone 7
I spent a few (no more than 2) hours on developing for Android, and the better half of a day building for Windows Phone 7 / Silverlight, mostly because I wanted to learn enough to understand the development model of both platforms, and compare said models to iOS's.
I went through Android source code when it was released ( spending most time on the 'Skia' 2d drawing component ) and figured out through the basic concepts. Its been a long time since then.
I was drawn to Windows Phone 7 because I really like the UI. Its clean, simple and elegant. Its also fresh and unlike iPhone's UI(everyone is copying Apple, left and right, as it has always been the case). When Silverlight was announced, I looked into it but was put off by the use of XAML files and some weird naming decisions in the classes tree. Other than building a trivial 'lets see what this is all about' application, I didn't spend more time on it.
As expected, Android and WP7/Silverlight also adopt the familiar views/controls paradigm. On Android, you got tasks (processes) and each holds a stack of Activities; an activity is more or less a page, that holds a content view. That content view is usually a container view that contains other views. Activities do not need to come from the task that owns the activities stack. They are popped out in a LIFO fashion, and its alls simple and nice. You also get services ( really, tasks with no front-facing UI, which are cool ), intents ( effectively, messages with action and payloads ) and other niceties.
It all more or less make sense - the one thing I don't like about Android is the UI of the controls. Everything is ugly. The emulator is also slow and, well, ugly, which makes things even worse than they probably are. Google is no Apple, sure, but they should have done something about it. It all reminds me of those Java Swing components (or even worse, AWT components used in Java Applets when applets were cool - which is a long, long time ago ). You get to use Java to build the applications. I am not fond of Java, but I don't really mind it ( a bit too high level for my taste, among other things). You also get to use Eclipse ( which makes it really easy to build stuff, with intellisense, on-the-fly compilation and all those nice things people expect nowadays from IDEs ), or use any other IDE or just use the tools on the terminal , if you don't like IDEs or for whatever other reason. That's what I did. The tools are easy to use and it takes very little amount of time to feel comfortable enough with the environment.
I spent an hour or so trying to find my way around Windows Phone 7 Silverlight concepts and paradigms. Those XAML files, that I hated on SL back in the day, were still here and I just didn't want to deal with them. It turns out, that unlike what the documentation may make you believe, you don't need to use them. You can delete them and do everything programmatically ( though its not straight forward, but it make sense once you do it once or twice ).
You need to decide if you want to build a Silverlight application, or an XNA application. If you want to build 'high performance' games, you need to build an XNA app. Otherwise you will want to build a Silverlight app. They are concepts and classes that are unique to each approach and it just doesn't feel right, having to restrict yourself to either of those as opposed to building an application that can access all facilities offered by the device. You are going to use C# to build Windows Phone 7 applications. C# is nice. Java on steroids. Visual Studio 2010 Express for Windows Phone is a free download from Microsoft, providing everything you need to build your applications.
So, you got your Application instance ( every WP7 application needs a class that derive from System.Windows.Application ). Every application instance has a RootVisual property. Its the main application UI ( a System.Windows.UIElement derived class instance ). The convention/requirement on Windows Phone is to have a special class instance set to RootView(PhoneApplicationFrame) and that should hold a PhoneApplicationPage derived class instance ). That page in turn holds a Content - which is the content view, etc. Similar concept to Android's activities and their content view, and iOS's Windows, Navigation controllers and their views. Again, simple stuff - just make sure you stay away from XAML documents.
By the way, there is no support for multitasking on Windows Phone 7, unlike Android and iOS. There is no supports for sockets, either, which is weird and rather sad ( Access over HTTP and 'web services' is not good enough ). Hopefully, this will change soon.
I am going to build a 'real' application for Windows Phone 7 in whatever spare time I have this week and submit it on their Market Place. It should be fun; if nothing else I will should learn enough to help our Mobile Unit folks at work with upcoming Windows Phone 7 projects.
Sunday, 17 October 2010 1:10 am
iPhone CSRs, Digital Certificates, Encryption and Cryptography
I have been reading about cryptography, digital certificates and signatures, symmetric and asymmetric keys based encryption lately(well, yesterday). Developing iPhone applications (and even more so deploying them to devices or the AppStore) involves dealing with certificate signing requests(CSRs), digital certificates, provision profiles, and more.
Apple went into great lengths to simplify the processes involved - for the most part its trivial and they guide you through every step. (alas, it wasn't always so; back in the day, code signing and other related processes were the cause of much pain among iPhone Developers ).
Nevertheless, whenever I come across something I haven't been familiar enough with, I can't help not 'wasting' time to learn it(how it works, why it works, etc). This practice has deprived me of many hours I could have spent elsewhere (working on other stuff, spending time with loved ones, whatever) but I just can't help it; I "need" to learn how things work.
So here is simplified, basics mostly, overview of those concepts, in case someone needs to get started with them.
The fundamental problems encryption solve are those of data integrity validation and identity authentication. That is to say, to verify that data(messages, anything) sent from Alice to Bob (Alice and Bob) can be verified by Bob that indeed came from Alice and that the data were not tempered with/modified in any way while they were in 'transit'. That's about it.
Encryption is the process of generating new data from the original data. The new data is usually unintelligible to anyone but the intended recipient. Decryption is the process of transforming that data back to the original data.
Those processes are facilitated by a cryptographic algorithm(a cipher). Mostly, this involves the use of a key(a number) which is used with the algorithm to perform the encryption and decryption. The same key is used for both encryption and decryption. With symmetric-key encryption, the encryption key has to be kept secret by both parties. If someone else gains access to the key, he can not only decrypt the data but also encrypt new data and send them to Bob and Bob would assume they came from Alice. That clearly is not desirable. Enter Public-Key Encryption.
Public Key Encryption(asymmetric encryption) involves a pair of keys. The public and the private key. The public key is published and is freely available. The private key is kept secret. Alice never reveals the private key. Ever.
The fundamental idea is that data encrypted using the public key can only be decrypted using the private key. Bob, who has access to the public key much like everyone else, can encrypt his message using Alice's public key, send it over to Alice and only Alice can decrypt it, for it is only one who has the private key.
PKE is computational expensive though and not always suitable for large amounts of data. Often enough, a hybrid approach is employed. PKE is used to send a symmetric key, which then can be used(since both parties will know that secret key) to encrypt additional data using symmetric encryption. Using a symmetric key to encrypt and decrypt data is far less computational expensive. SSL and other protocols rely on this hybrid approach.
It is also possible to encrypt a piece of data using a private key which can only be decrypted using the public key. Given that Alice shared her public key with anyone interested, that wouldn't make much sense if Alice was to send data to Bob encrypted with her private key. Anyone could read it
Well, it does make sense, thanks to digital signatures. A digital signature can be used to verify that data sent from Alice - encrypted or not - were not modified in any way by the time Bob received them. In other words, it validates the authenticity of the data. It deals with tampering and impersonation.
Alice will use a hashing algorithm to generate a signature out of the message she wishes to send to Bob. That signature will then be encrypted with her secret private key. Then, she will send both the data she wishes to send to bob and the encrypted signature she generated from that data. It will also send Bob information about the hashing algorithm Alice used to generate the signature of her message.
Bob will use Alice's public key to decrypt the signature. Then, he will use the same hashing algorithm to generate a signature from the message he received. If the signature matches the signature Alice provided him with, it means the message is authentic. That is so because only Alice knows the private key and only Alice could have encrypted the signature like that.
Unless Alice lost her private key, it is 'impossible' for Alice to deny that she signed the data she sent to Bob, or for anyone to 'sign' anything, send it over to Bob and claim she is Alice.
A hashing function converts data into a single value (often a big integer). Hash functions are fundamental in the design and implementation of some of the most important data structures.
There is one last issue that needs to be addressed. Confirming identities. Digital Certificates solve this problem.
A certificate is an electronic document that is used to identify an entity(individual, company, anything) and associate that entity with a unique public key. Your passport identifies you and associates bits of information with you (your name, etc).
Public Key cryptography uses certificates to address impersonation problems.
Much like one would go about obtaining a driving license, by providing the authorities with whatever information and credentials required, so that they can verify the identity of the applicant and then issue her the driving license, Certificate Authorities(CAs) serve a similar purpose.
They will get Alice's application for a certificate (which includes her public key and information about her), they will validate the information she provided is correct and indeed represent her, and then issue her a Digital Certificate.
In essence, the Digital Certificate binds a public key to an entity. They help prevent the use of fake public keys. So, the digital certificate contains the public key of the entity, its name and other information (key/value pairs, e.g name=Steve, organization=Apple, Inc.) It also includes the digital signature of the CA. It is that digital signature that allows the certificate to function as a verified and trusted certificate, by users who know and trust CA (in other words, have the CA's public key and know that that public key belongs to that CA) and trust the CA but do not know the entity identified by the certificate.
Apple is a Certificate Authority. Before deploying your iPhone application to a device, you need to obtain a certificate and a provision profile. So you prepare a Certificate Signing Request(CSR). This contains information about you. It is the information you want Apple to verify. When you create the CSR, the public and private keys pair is also created. The public keys is included in the CSR. The private key is never sent to Apple. The private key is used for signing your binary.
Apple will get your CSR, create a digital certificate based on it. Then, you need to create a provisioning profile. The provisioning profile holds application IDs, device IDs and certificates.
You will need to submit CSRs and install Digital Certificates if you need to deploy and distribute iPhone applications, use Apple iPhone Notifications and In-App purchases. Hopefully this helps understanding why those are needed and what they are about.
Saturday, 27 March 2010 11:01 am
