Progress with Android

I was finally able to work a little more with the Android port this week. You can now select a guitar from the new guitar selection form and have it update the fretboard. My next goal is to add selectable pedals and levers to the fretboard display to hopefully get an alpha release ready for Google Play.

Screenshot_1531020653Screenshot_1531020657

Android Development with Linux and Ryzen

Apple macOS is my primary environment these days but I have a PC I like to work with that has gone through quite a number of upgrades over the years. I recently upgraded to an AMD Ryzen 5 1600 CPU and motherboard.  Even though Android has not been my primary development platform I have kept up with Android development going back to the days of Eclipse then Android Studio when it became the official Android development tool. I have been a little frustrated with the Android development environment after spending a lot of time in Xcode and Visual Studio over the years. The Android Studio version 2.0 release seemed very good to me but the emulator performance and build times had still been a little disappointing.

After upgrading I was interested in seeing how Android Studio would run on my upgraded PC in Windows 10. I anxiously downloaded the latest version 3 release and nothing felt like it really changed from my AMD FX CPU. I did not time anything or run any benchmarks but in general nothing really “felt” different. Also, the AMD processor does not support HAXM which in theory is supposed to make the Android Emulator run almost as good as the iOS simulator on macOS.

After doing a little searching I discovered that the Android simulator is fully supported under Linux even on AMD. I had used Linux back in the days of Slackware in the late 90s and can remember installing Red Hat 5.0 but after working primarily on mobile apps for over four years now macOS and a little Windows are all I have really worked on during this time. The last time I used Linux on the desktop Linux Mint was my preferred distribution and it still held the #1 spot on DistroWatch.com so I went with that.

The Linux Mint install was quick and painless. I did a little research and found Android Studio (and a lot of other development software) can be installed quite easily on Ubuntu systems with umake. A little more setup and I was up and running. I did not benchmark anything but everything was snappy and quick. The Android emulator came up without any issues and it was the fastest I have ever seen it run on any of my systems. I am very impressed. I am going to continue with this Linux as my primary OS for Android development but I am sure macOS will still be used as well. I am going to pass on Windows 10 for now at least with AMD.

Screenshot from 2018-01-13 23-55-20

IMG_2082

Progress with Android

I have been working on the Android version of Steel Sidekick and in the process I feel I am making some real progress learning about this platform.  One thing that has been intersting to me is how similar Auto Layout on iOS and Constaint Layout on Android is. While searching for more information on how to better use Constraint Layout I stumbled upon this article:

https://www.bignerdranch.com/blog/constraintlayout-vs-auto-layout-how-do-they-compare/

It looks like Auto Layout and Constraint Layout are both based on research documented in  “The Cassowary linear arithmetic constraint solving algorithm“. Interesting! Anyway, at least we have a layout system very similar to each other on both platforms.

 

 

Preparing Steel Sidekick for iPhone X

I just pushed an update of Steel Sidekick to the App Store to support the iPhone X screen resolution. The new “notch” for the camera was causing some issues.

iPhoneX-Before

I used the new safeAreaLayoutGuide on the UIView to determine where to display the fretboard.
if (@available(iOS 11.0, *)) {
  CGRect safeRect = [self.view.safeAreaLayoutGuide layoutFrame];
  left = safeRect.origin.x;
}

After trying a few different layouts I ultimately decided to move the fretboard into the safe area and extend the strings under the notch.
iPhoneX-After

If you have an iPhone X and download the latest version the notch should no longer hide the open string notes.

Thoughts On Cross Platform Mobile Development

I have been experimenting over the last few years looking for the definite answer to cross platform mobile development. These are some of my thoughts after evaluating some approaches.

Hybrid – Cordova/PhoneGap

Write the app in HTML5 with Javascript. Most of the user interface and code work across Android and iOS. I have done a lot of this at work recently. The big issues are on older version of Android without an updated HTML5 webview. I have also found JavaScript not to be a very good language to write a large, scalable application in although TypeScript/ES6 may change my mind about this. This approach I feel gives advantage to the developer and takes away from the user by not giving them a full native experience on the platform.

C++

I tested this approach with my Steel Sidekick application. The entire non UI is written in C++. The fret board view is using OpenGL ES for Graphics. Since OpenGL ES runs on both Android and iOS (as well as Windows and Mac) I can even use some of the UI code across all platforms. The only implementation needed for a new platform is the UI interface. I still need to complete the Mac and Android portion. A lot of companies are using this approach. The Microsoft Office and Dropbox mobile apps all use C++. I had not used C++ recently and it was nice going back to it but you definitely cannot jump into it like JavaScript.

Java (using J2Obc)

This approach has all the non-UI code written in Java. The Java code can be used on Android and on the web using GWT. On iOS the java-2-objective c process translates the Java code to Objective C which can then be imported into the Swift/Objective C project on iOS and Mac. This is the approach used by Google. Google is heavily backing the j2objc project if commits to the GitHub project is any indicator.

Xamarin

Microsoft implementation (through acquisition) of the Android and iOS API in C#. The native code is all written in C# instead of Objective C/Swift on iOS and Java for Android. The non-UI code is shared across Android and iOS. The native API’s are exposed in C#. It seems like a good choice especially for Microsoft shops. It was one of my top picks when we evaluated it at work. In the end it does not seem to much different than the C++ or Java. The native code is written in C# which I feel is a little non-standard but it could work. I am going to investigate this in more detail.

ReactNative

Most of the  app code is written in Javascript. The native API is exposed as Javascript. It is a little like Xamarin. If the native toolkit does not exist on your platform you still need to write code Objective C/Swift on iOS or Java for Android. This seems to have a lot of momentum behind it. Facebook is backing this project. The Facebook mobile app is written in React Native. I did not think this was a good choice when I first investigated it but it is growing on me as I look into it further.