This article was written by an independent writer, Jeff Cogswell. The article is sponsored by Microsoft Corporation, which offers tools and resources for helping developers port from Android to Windows 8.
A few months ago, the upper management at a company I was consulting for made the bold move to start switching all corporate phones from Android to Windows 8 Phone. While the employees seemed more concerned about the time they would spend moving their Words with Friends friend lists over to the new phones, the software development team had a bigger issue on its hands: There were several internal apps it had developed for the Android devices. One such app was an expense tracker. While there were plenty of good expense trackers available both in the Google Play Store for Android and the Windows Store for Windows 8 Phone, upper management was convinced that the in-house Android app was superior because it had been built specifically for them. No complaints there; I was hired in on contract to help assist porting the application. I originally helped them build the app for Android a couple of years earlier.
The following are two screen shots of the Android app running inside the Android emulator.
For building our Android app, we used Eclipse, and only later realized we probably would have had an easier time if we had used IntelliJ. Building the original Android app wasn't particularly easy compared to our Visual Studio experiences. The programming language, Java, is pretty good but working with Visual Studio to develop for Windows 8 Phone proved to be as easy based on having used it in the past for Windows and ASP.NET applications.
As we started out the porting process, right off the bat we made sure the team was aware of two things:
- We would have to rewrite the code. While C# shares similar syntax as Java, the code doesn't instantly port. But that's fine; we're programmers and programming is what we do best. (And as you'll see this actually proved to be pretty easy.)
- We would re-think the GUI. Although we're dealing with similar screen sizes and usability features, the Windows 8 Phone and Android devices are still quite different, and the users expect a different experience. Yes, we could have stuck with the same Android look and feel, but we wanted to embrace the full Windows 8 Phone experience so our app would feel natural alongside the other apps on the device.
There was quite a bit of good news as well. Although we would still have to do some coding, the Windows 8 Phone API is rich with controls and classes that make programming for Windows 8 Phone fast. Our team has extensive experience with both Java with Eclipse and C# with Visual Studio — and while debates can go on and on for years over which is “better” — our team's own experience is that Visual Studio has superior features in terms of how quickly we can build an app.
As a software engineer with 25 years of experience, I still like to spend as little time coding as possible, and instead focus my efforts on usability. The combination of Visual Studio tools and the rich .NET API makes that a reality. As you'll see in the next installment, this proved to be extremely easy. For several parts of our new Windows 8 Phone application we didn't even need to write any code; some of the code we had written in Java were now a matter of clicking through a designer.
We also realized early on that our primary Java data structures should be easy to port. A properly designed class should port well to any decent language. That's an important point for software development in general: Whenever you build an application, whether you expect to port it or not, you want to use sound software engineering principles. This includes building well-designed classes.
Different people have different ideas on what constitutes a well-designed class, but for us it means not going overboard on the sheer number of classes and not building a massive inheritance tree. But it also means using fundamental principles like separating our data structures logically into different classes and not making too few classes. This was the policy we followed when we built the original application, long before we realized we would be porting it. And not only has it helped us in the porting, it also helped us as we were maintaining the app.
This application had two main classes for the data in the original Java code, which we would port directly to C#:
- Project: When an employee goes on a trip or starts a new work project, the expenses need to be associated with the trip or work project. The Project class represents a trip or work project. (Originally we were calling it “trip” but the project managers wondered why we were focusing only on business trips. To us it didn't matter since “everything is a widget” anyway, and the name doesn't really matter. But we ended up renaming it to “Project” in the design docs and subsequently the code used that name.)
- Expense: This is an individual expense item.
Each project has a name, a date, and a corporate-assigned project ID, as well as a list of Expense objects.
An individual Expense object has a name, an expense type and an amount. One suggestion during the original Java development was to create a base Expense class, and from there derive several new classes, one for each type (meal, hotel, and so on), in the spirit of true, hard-core Object-Oriented Programming circa 1995. But ultimately this data needs to be mapped to a flat database. While bigger, more sophisticated applications might benefit from heavy polymorphism, with this small app there was no real benefit to creating all these extra classes other than to pat each other on the back on our superior Object-Oriented programming skills. Instead, skipping the inheritance and simply including a “type” member did the trick.
The classes, then, should be easy to port. We decided we would just translate the classes from Java to C#. The member variables would be a straight translation. We would comment out the code for the member functions, and use it as a guide in re-writing the code.
From a database perspective, we had put together a rather simple set of tables that mapped easily to our classes. The main two tables were Project and Expense, which mapped the structure of the classes. The two classes were basically flat, as they just had a list of scalar members, except for the Expense list in the Project class. While we could have used an object-persistence database, such as one from Versant, instead we were able to easily store and retrieve our objects in the SQL database using a primary key in the Project table that maps to a foreign key in the Expense table. This worked just fine. (If our classes been more complex, we might have explored other alternatives.) As a result, translating the database from Android SQLite to Windows 8 Phone's SQL database would be a snap.
As for the coding, storing and retrieval of the data, our engineers were very familiar with the LINQ features of C#. Although LINQ doesn't exist in Java, and as such our code would look radically different, we decided that LINQ is so quick and easy to code for that it would be no problem completely rewriting this part. Typically in porting you want to try to maintain similar code bases, but in this case we felt that LINQ was so easy to use that if we had to change the original Java app for whatever reason (such as adding more classes that would need SQL storage or adding members to our original classes and tables), we could just as easily change it in the Windows Phone app as well.
In the next installment we'll look at some of the actual code; for example, you'll see that our decision to embrace LINQ proved to be a good one, as we were able to write the object-persistence parts of our code extremely quickly. Also next time we will explore the designs that gave our newly-ported app a beautiful Windows 8 look and feel.
Editor’s Note: Continue to page two for the next installment!