a quick comparison of olympus oi.share on android and ios

You’re looking at the Olympus OI.Share app running on a Moto G5S Plus with Android 7.1.1 on the left and on the right an iPhone 8 Plus with iOS 11.4. Both Olympus apps are at the latest release on both platforms.

They run nearly identically (allowing for differences between the respective smartphone operating systems) with one very notable exception: loading photos from the camera to the smartphone. The camera in question is my Pen F. I’m at the point where I want to use my Pen F to perform documentation, and then use OI.Share to move those images over to the smartphone for either direct sharing (Google Drive, Instagram, etc) or further processing (Snapseed, VSCO).

When I attempt to move a photo from my Pen F over to the iPhone using OI.Share, it takes nearly forever to move that photo, to the point where I want to pull out the SDHC card and use the Lightening to SDHC/SDXC adapter, which is still slow, but faster than OI.Share on iOS. Today I installed the same Olympus app on the Moto G5S Plus, and was absolutely stunned at the high speed with which the app was able to move photos off the Pen F. It is literally minutes of wait time on the iPhone vs seconds on the Android handset. I have no idea what is happening, and I’ve often cursed the Olympus iOS app for its glacially slow speeds. The only app that is as fast as this on iOS is the Panasonic app I use on the iPhone to transfer photos off my GH4. Which was one of the big reasons for taking the GH4 instead of the Pen F nearly everywhere because it was just so much more convenient to use with my iPhone.

That makes for some interesting possibilities going forward with the Android. In spite of the fact that my daily driver phone is an iPhone 8 Plus, I own mid-range Android handsets because they’re inexpensive ($200 or less when you find them on sale) test hardware with more current versions of Android, which I tether to my MBP and use as physical test devices when writing Android apps (the emulators are plain horrible speed-wise; always have been). And a piece of hardware means I can pick it up and directly touch the screen to test its functionality. Right now, I have a Moto G4 Plus with Android 7 and a Moto G5S Plus with Android 7.1.1. I’m contemplating getting a Nokia 6.1 because it’s alleged to have at least Android 8, and perhaps even Android 8.1, and it’s another mid-range Android handset for around $260. I use them for software development and testing, but they don’t have SIM cards, and thus they’re not a “real” phone. They’re on the net via WiFi only, and nothing else. Frankly I’d rather like to keep it that way because I don’t trust Android’s security any more when it’s not behind my firewalls.

But I still want to know why the radical speed difference between running on iOS and Android. And the same difference between Olympus (slow as molasses in winter) vs Panasonic (quite speedy).

If anyone reading this might know why OI.Share could be so slow on iOS and a way to speed it up, please drop me a comment.

an example of migrating older android projects to android studio 3

In the last post I spoke of getting back into some semblance of Android application development. Part of the effort was the migration of Deitel and Deitel example applications from “Android 6 for Programmers, Third Edition.” What follows are the specific steps needed to move these example applications into Android Studio 3.0.1. In the process I’m going to begin to move the applications from Android 6 to Android 7.1.1. In this post example I’m going to migrate the WelcomeInternationalized app.

First, open the project and load it into Android Studio. Android Studio will attempt to load the project using the project’s default Android SDK location. This will fail, but this is normal, and Android Studio will automatically correct it for you.

After changing the Android SDK location, Android Studio finishes opening the project and attempts to build it. This creates the first error.

This is caused by one of two Gradle build files.

Go to the file navigator on the left and expand Gradle Scripts. Open the top, or project, build.gradle file. Highlight the first line in the dependencies block (line 8 in the example above). That’s what’s causing the project build failure.
With the line highlighted (the cursor placed on the line) a “lightbulb” will appear to the left of the line with a dropdown arrow. Click that arrow for the dialog above. The first entry on the dropdown is to change the version to 3.0.1. Click that, and then resync the project by clicking the “Try Again” link. Note that you can also simply type in 3.0.1.
You’re still not done. Now the build process complains of the Gradle wrapper. Click the hyperlinked line in the error to fix this second error.
At this point the project has rebuilt with just one warning. Let’s get rid of that warning.
Open the second build.gradle file, the one labeled (Module: app) and comment out the buildToolsVersion line (line 5 in our example). As the warning says, this is no longer needed. Then rebuild the project again by clicking “Sync Now” in the upper right. This final tweak will result in a clean build with no errors or warnings.

So far I’ve done a bit more with the Dietel and Dietel example applications than just move them over. The examples, written for Android 6, are solid examples and interesting in what Android 6 capabilities they expose to the student. They’re worth “upgrading” and moving along into Android 7.x and even Android 8. But to get to that point you need to be able to work with any of them in Android Studio 3.

It should be noted that the original examples were written in an environment running Java JDK 7, Android Studio 1.4, and Android SDK 23. My environment is running Java JDK 8 u152, Android Studio 3.0.1, and Android SDK 25/7.1.1/Nougat.