MobileAndroidPorting from Android to Windows 8: The Real Story

Porting from Android to Windows 8: The Real Story content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

Android app running inside the Android emulator       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:

  1. 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.)
  2. 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!

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.

As my team ventured forward with porting our original Android app to Windows 8 Phone, we were surprised with not only how smoothly it went, but with how quickly we were able to get the job done. Many parts that required Java coding in the Android version didn’t require any coding at all. Instead we were able to use the Visual Studio designer to lay out the controls, and quickly attach the code to them. The screenshot below shows the designer as we were laying out the controls on the main page.

the designer as we were laying out the controls on the main page

Creating the different pages was as easy as adding, clicking New and choosing Windows Phone Portrait Page. To navigate from the main page to the next page required a call to the NavigationService object’s Navigate function, like so:

private void ApplicationBarIconButton_Click_2(object sender, EventArgs e) {

    NavigationService.Navigate(new Uri("/NewExpense.xaml", UriKind.Relative));

This, of course, was completely different from how we accomplished navigation through the Java code and Android. But given that we were able to quickly design our controls, and accomplish navigation with a single function call to Navigate, this was no problem whatsoever.

Meanwhile, as we were rebuilding our screens for the Windows Phone device, we were able to factor in a few changes after feedback from our employees regarding their usage with the Android version. There were a few usability issues that needed correcting. For example, the original one had a calendar that was accessible from the front screen; the employees really didn’t find that feature particularly useful. Instead of searching for projects by date using the calendar feature they wanted easy access to the project list from the front screen, whereby they could search for the most recent couple of projects. We decided to replace the calendar with a sorted list of the projects.

The sorting would use the date of the most recent expense item. That way, if a project was ongoing for six months, and had an expense added just yesterday, for example, it would appear toward the top of the list, ahead of a project from last week that lasted only one day.

This meant that although we were porting the app, we were also doing a version upgrade. Originally the senior management balked at this idea. To non-technical folks, creating new features seemed more difficult and time consuming than just porting. In their eyes, we should first just port the existing product, get it working, and then think about adding new features. Fortunately we were able to convince them that development really doesn’t work like that. Instead, this opportunity was the perfect time to add new features, because porting is never a matter of simply recompiling the code under a different platform. We were going from Java to C#, and we’d be rewriting large sections anyway.

This caused some concern among executives because now they were worried that porting wasn’t so easy and it would take much longer than we thought. We came up with an easy solution: to convince them that it wouldn’t be bad at all, we took a laptop into the conference room with them, launched Visual Studio, created a new Windows Phone project, dropped some controls on the page that looked basically like our expense tracking program, and then created a second page. The whole process took less than five minutes. They were stunned at how quickly we did that, and we made our case. They approved the project to move forward.

Other aspects of the system, such as the database, required some recoding, but again, it wasn’t a huge problem. We used Microsoft’s LINQ to SQL technology, which mean we could quickly do queries and save information to the database with only a few lines of code.

In the end, we created a beautiful app that worked perfectly on Windows Phone. The only part that really took a little more time (a couple extra days) was uploading the expense sheets to the internal server. The server was already set up to receive expense sheets from the original Android application. This worked by connecting to the server’s internal IP address, and logging in with the credentials saved in the app. This again required some rewriting in C#; however, the API made it easy to simply initiate a TCP/IP connection and send the data up. That meant that we had to reconstruct the data structures in the exact same format used in the original Android application. Fortunately, we used JSON for that, and it was a snap to convert our structures to a JSON format and push it up. In the end, the server really didn’t know or care whether it was the old Android app or the new Windows Phone app sending the data.

We also had a synchronization process running on the server that would handle repeat uploads. The server would go through the expense sheet, and look for any changes or updates. If there were changes, it would update the server-side data accordingly. Because this code lived on the server, we didn’t need to rewrite any of it to handle the Windows Phone code.

It also meant we could roll our changes out gradually. Initially a couple members of the IT team switched to the Windows Phone version of the app, while everyone else continued using the Android app. Once we were happy with the results, we could start switching everybody else. And in the end, it all worked beautifully. Below are two screen shots of the final application.

the final application       the final application


Software developers enjoy programming, which is why they chose their profession. Sometimes, however, there are parts that aren’t fun. In the end, most of us agreed that this was a fun project. Visual Studio was a joy to work with, and we were able to produce code quickly and easily. The Windows Phone was fun to use. Although we couldn’t simply just recompile the code for Windows, rewriting it in C# allowed us to work in a few new features. And it didn’t take long at all. Developing for Windows 8 Phone is a fast, smooth process, and the entire project was a big success.

This article was written by an independent writer, Jeff Cogswell. The article is, however, sponsored by Microsoft Corporation, which offers tools and resources for helping developers port from Android to Windows 8.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories