Posted on

Samsung Galaxy S5 Random Factory Reset

Yup, here again. Setting up my Samsung Galaxy S5 after a random factory reset. Unfortunately, in today’s connected world the phone has become the linchpin of my techno-geek world. My two-step authentication system ensures it takes an extra 20 minutes to log into any service I care about when my phone is MIA. Thousands of messages, contacts, and other data needs to be re-downloaded into the phone so I know who (843) 555-1212 is on SMS or when a telemarketing agency is calling. It takes HOURS to reload all the moving parts.

Galaxy S5 Reloading. Again.
Galaxy S5 Reloading. Again.

What a huge pain!

Turns out I’m not alone.

Random factory resets of Samsung Galaxy S5 phones are a known phenomenon that apparently Verizon and Samsung are content to ignore. Too hard to reproduce so it must be user error. Or a bad app. Couldn’t possibly be an issue with Samsung’s hacked version of the Android OS or bad firmware, right?

Android Lollipop Barfing

The most likely and most common problem with the random factory reset appears to be related to corrupted cache files in Android OS after a system upgrade. Interestingly, all 3 times that my phone decided to just reset for no apparent reason it was within 2 weeks of an Android Lollipop update pushed out by Samsung.

Very coincidental, isn’t it?

Turns out that the fix is… A HARD FACTORY RESET.

Wonderful. The only solace with that fix is that you may get to spend the two hours reloading your phone during a time in your life when it is the least inconvenient.

Really not much different than a random reset, but at least you know its coming.

To start the process power off your phone then hold down the power, volume up, and home button at the same time. When you see the loading screen with blue text at the top you can release the buttons. Follow the on-screen menus to do a full factory reset and data wipe.

Yes, this is like getting the phone for the first time. Yes it sucks. Yes you will need to reload all your stuff (you do use Google and Samsung and a third party backup service right? You’ll need all 3 if you don’t want to re-invent the wheel every time this happens). No, your home screen, keyboard, and other configuration settings will not come back. Now you know why so many Samsung S5 users have the default screen. Why customize when you’ll be back to that default in 3 months whether you like it or not.

Bad Battery

Very rare.  However if your battery is defective it will overheat and warp.  Take the battery out.  Put it on a flat surface.  If it does not lay flat on the table you need to replace the battery.   Good luck getting it repaired under warranty.   Luckily batteries are inexpensive.

Bad Apps

Some sites, typically Samsung or Verizon-driven forums and support personnel, claim apps can cause the factory reset.  Sure.  Very unlikely as that is a HUGE security nightmare in Android OS, but I guess anything is possible.   The suggested fix is randomly delete apps that were loaded on your phone until the problem goes away.   Uhhh… exactly how often does a random factory reset happen?   That is like closing your eyes in a dark room, spinning around in circles, and trying to pin-the-tail-on-the-donkey without ever turning on the lights to know if you were successful.

Personally I think this culprit is nothing more than fairy tales and pixie dust to keep you busy and away from the support people.

Samsung OS Updates

Ultimately I think Samsung and Verizon need to stop screwing with the base Android OS builds to cram in a ton of crappy apps nobody wants.   Those apps are nothing but modern day spam that most people don’t want.  They consume excess memory and screen real estate with the only purpose being to line the pocket books of Samsung for hocking other people’s wares.   Wake up.   Nobody wants your crap and if they could delete all the force-fed shit on the phone for more memory and storage space and less app problems they would do it in a heartbeat.

Stop “tweaking” the OS and make a stable version that does not randomly reset every few months.

IOS – The Gold Standard

Sadly, if they ever DO make that version there will be more-and-more people like myself that will refuse to install the update for the ever-present fear of incurring the curse of the random reset.   Instead many people will be in the same situation I am.  Just waiting for my 2-year contract to expire so I can finally stop fooling myself into thinking that Android will every be a gold standard.   iPhone IS the gold standard which is readily apparent by every single device-and-service you could ever want to use granting Apple front-of-line status and relegating Android users to play the role of red-headed stepchild.    Starbucks.   BMW. Smart Lock.  Smart Home.  And big luxury brand has full-feature apps on IOS and half-baked crap and Android.

 

Posted on

Invalid Binary iTunes Connect

After several days of trying to get an iOS application loaded in our Apple Store account, we finally figure out the problem.  While we’ve had success with other application uploads in the past, this application build with Rhomobile was particularly problematic.    Turns out the issues was with Xcode corrupting the PNG files when compressing them for the archive.

Invalid Binary? Tell Me More…

However the Application Loader, the recommended application for getting your apps into the iTunes connect store, was not very helpful.  We would upload, no errors, no email and then see “invalid binary” moments later when checking our iTunes connect listing.   The first trick to resolving the issue was getting a proper message back from Apple as to what was wrong.

Build & Archive

A lesser-known method for deploying to the app store is to use the Xcode archival tool.   First build your app with Xcode using the product/build menu.   Then use Product/Archive to create the archive for distribution.  Normally this will open the Xcode Organizer window and select the archive tab for you.   If not, you can get to the Xcode Organizer via the main Xcode menu.

From here you can validate and distribute your application in separate steps.  In our case validation and distribution both went without issue.   However the BIG difference was in how Apple handled our upload after the process was complete.  For some reason this distribution method triggered something over on the Apple servers that got them to send us an email.  “Invalid PNG format for icon144.png”.  Great, now we’re getting somewhere.

Corrupt PNG, Really?

Our PNG file opened without any issues in a number of editors as well as the Preview application that came with OS/X.   It renders in a browser.  The original PNG was just fine.    What was going on here?

After some digging around on Google we found some deep down posts about “invalid PNG” files and how Xcode is corrupting some, but not all, PNG files.   Turns out the default build settings has compress PNG turned on.    Turning this off seems to help.  In XCode select your target project, go to build settings and expand the package section.   Compress PNG is one of the first settings and is often set to yes.  Toggle this to no and rebuild.

Sure enough, in our case, the PNG was not longer flagged as corrupt.

There are a myriad of other things that can cause your app to generate the Invalid Binary message, but this is one more possible fix that may get you to the next step.

Good luck battling the Apple Store with your app efforts!

Posted on

Phonegap Barcodes on IOS

Introduction

This article covers building barcode scanning apps on IOS (iPhone/iPad) with Phonegap.   For reference, Phonegap is going to become Apache Cordova any day now, so the process can be confusing if you are looking at older materials.  Before we get started we make the following assumptions about your development environment:

  • Operating System is OS/X Lion
  • Your IDE is XCode 4.2
  • You have installed Phonegap 1.5.0 or higher
  • You have downloaded Phonegap Plugins

While the general process will work with newer and possibly older versions, this is the environment we have tested this process with.   Also, if you mix versions of Phonegap and the plugins you will have naming convention problems, especially if you mix recent plugins with and older Phonegap install or vice-versa thanks to the transition from Phonegap to Apache Cordova.

We recommend following the links above as Google search results may bring you to older code.   We also recommend that if you had an older version of Phonegap that you install the latest version and start a new Cordova project via XCode with the new install.    Once your test app is successful you can follow the Upgrade Guide that will be included in the docs section of the downloaded zip file.

Our example app is named “abundascan”, which is also the default target that was created.  You will see that name in the screen shots included herein.

Step 1: Build A Starter Cordova App

Start Xcode and create a new Cordova project.  Build your project and run it in your simulator or directly to your connected IOS device.  This will build the template project.

Step 2: Add The Cordova Source Files

After you’ve downloaded and unzipped the files from the Phonegap Plugins page you will have a phonegap-plugins folder full of various plugins.   There will e a subfolder named “BarcodeScanner”.  This is the folder that will have the contents you need.

Highlight the following files and drag them from that folder over to your XCode window and drop them under the <target_name>/Plugins subfolder:

  • CDVBarcodeScanner.mm
  • zxing-all-in-one.cpp
  • zxing-all-in-one.h

Step 3: Edit The Cordova Plist

This file provides the symbol table references that will be used to connect the JavaScript components to the compiled plugin.    Find the Supporting Files folder under your <target_name> folder and click on Cordova.plist.

This will show the key/type/value table int he main editing window.  Click on the arrow next to Plugins to expand that section, then hover over to the right of the word “Plugins” to get the add/subtract entry buttons.  Click the plus to add a new empty line.

In the new line enter org.apach.cordova.barcodeScanner as the key name.  Note the capital “S”.

In the value column enter CDVBarcodeScanner.

Step 4: Add Link Libraries

In order for the project to compile in the new BarcodeScanner library you will need to add some new core libraries to your build commands.   In Xcode click on the target in the left hand sidebar (this is usually the topmost line under which all other items reside).   The project summary should appear in the main window. Click on the Build Phases top tab.

Open up the first Link Binary With Libraries group.   At the bottom of the expansion is the add/remove buttons.  Click on the + to add a new library.    Type in the following names (partial search will work) and add these libraries to the list:

  • AVFoundation.framework
  • AssetsLibrary.framework
  • CoreVideo.framework
  • libiconv.dylib

Note: You may need to click on the IOS5 folder when the quick search is running to see your matches.  

Other Settings

ZXing.cpp Optimizations Off

You may also need to turn off optimization for the zxing-all-in-one.cc file.   To do this, expand the compile sources group.  You will see a half-dozen file names with the last one likely being zxing-all-in-one.cpp.    This is actually a 2-column listing, if your screen is not wide enough you will see a “C…” trailing on the top right of the group.  Go just to the left of this and move your mouse in the header slowly, you will see the expansion double-headed arrow.  Click and drag to the left to expand this column.   Now double-click in this column to the right of the zxing-all-in-one.cpp file and add -O0 (letter “oh”, number zero) and click done.

No ARC

Do not use ARC (Objective-C Automatic Reference Counting).  If you did not turn this OFF when starting your project you can go to the Build Settings tab, scroll down to the Apple LLVM compiler 3.0 – Language group, expand it, and look for “Objective-C Automatic Reference Counting) and set it to no.

Add JavaScript and Run

Now you just need to add the reference to the barcodescanner.js file in your HTML files for the app and bind a click or hyperlink to the JavaScript barcodeScanner.scan_code call.     Run and you should be able to activate the scanner.

 

Posted on

Mobile Cross Platform Development : Corona

Anscamobile CoronaWe recently wrote an article on our experience using Apache Cordova to build cross-platform mobile devices.   It works for quick prototypes or simple mobile apps but the are compromises.   Here we touch on our experiences using Corona by Ansca Mobile.

Testing The Apps

One of the things we dislike about Corona is the fact that testing on an ACTUAL DEVICE is a cumbersome process.  The short version, build the app, find your OS level tools, manually push the app into the phone.  Doesn’t sound hard until you start playing with command-line tools to move stuff around.  Yeah, we are tech geeks, but who wants to see this sort of thing constantly during the build/test cycle?

Corona Android App Install

Another fun “feature” of this method is what happens when you are UPDATING an app for testing.  Since you are using the command line the process of updating needs to be done in a 2-step process, UNINSTALL first, the install.  Forget to uninstall and you get an error.   What is a simple 1-step GUI operation in Eclipse with Cordova becomes a 2-step command-line operation in Corona, and that becomes 3+ steps if your command line interface is not already open.

Cordova Wins This Battle…

The Eclipse interface used with Apache Cordova is FAR EASIER.  Select “run”.  If a single mobile device is attached it loads and runs.  If more than one is attached it asks “one which device”.  If none are attached it runs in the simulator.

Corona wants to ALWAYS run in the simulator. The simulator is good, but not great.   We often see graphic anomalies.  You also have no way to test the camera, or other real-world things like degree of tilt, etc.  Testing on a real-world mobile device should be 10x easier with Corona.

Documentation Out of Date

There are a number of areas where the documentation for Corona is out-of-date.   This is a huge problem for people not familiar with the Corona builds.   Sadly you often have to search the forums to get accurate functionality from other Corona users.    For example, the Android GPS permissions are documented in the Corona API and Build settings with obsolete settings:

settings =
{
android =
{
versionCode = “3”
},

androidPermissions =
{
“android.permission.ACCESS_FINE_LOCATION”,
“android.permission.INTERNET”
},

orientation =
{
default = “landscapeRight”
},
}

The proper settings are noted in the forum:

In Corona, you can add these <uses-feature> tags via the “build.settings” file as follows…

settings =

{
android =
{
usesPermissions =
{
“android.permission.ACCESS_COARSE_LOCATION”,
},
usesFeatures =
{
{name=”android.hardware.location”, required=false},
{name=”android.hardware.location.network”, required=false},
{name=”android.hardware.location.gps”, required=false},
}
}
}

With a note by a Corona guru …

We added “usesPermissions” and “usesFeatures” as of build 704. We haven’t documented them yet. So, I apologize for the confusion.

Sadly this note is over 2 months old and the documentation is still wrong.

Android Features Missing

One of the problems with Corona, as noted in our prior article about Cordova, is that there is no support for some device specific features.  Two of these , camera and orientation change, are key to many mobile apps and quickly eliminates Corona from consideration.

From the Corona website Android build docs:

The following features available for iPhone devices are not yet implemented, or fully implemented, for Android device builds:

Camera
Activity indicator
Orientation changes
OpenAL audio: limited support

More shortcomings, in our first attempt we find out we can’t use the map API, which sucks as we are building a map application.

MapView is currently iOS-only, and therefore will not run in the Corona Simulator. Build for iOS devices or for the XCode Simulator to use this feature. For an example of many of these APIs, see the new “MapView” sample project distributed with the SDK.

From the Corona Map API page

Notes about the Android issues, which affect Kindle Fire and Nook, are prevalent:

On Android, the default orientation setting has no effect. The orientation is initialized to the actual orientation of the device (unless only one orientation is specified). Also, the only supported orientations are landscapeRight and portrait. On a device, you can flip to either landscapeRight or landscapeLeft, but the OS only reports one flavor of landscape, and Corona’s orientation event chooses landscapeRight.

From the Corona Configure Projects page.

Vendor Lock-In

Perhaps one of the most troublesome issues with Corona is the vendor lock-in.   When using this system you only retain and have control of the Lua code.   The problem is that the pre-processors and compilers run on THEIR servers. That means Corona has the actual source code for the Java and Objective-C version of your Lua code.

If Anscamobile goes out of business, you are out of luck.   If you let your subscription expire you are out of luck.  If they raise subscription prices by 5,000% you are in trouble.   If their servers crash, your internet connection drops, or any other number of issues come up you cannot update your apps.

If you go this route you are absolutely tied into & dependent on Corona for your mobile apps survival.   Is that part of your business plan?  Is Corona listed as a business partner?  If not, they are a partner now whether you like it or not.

Summary

It is very clear early on in the evaluation process that Anscamobile’s Corona environment heavily favors and is geared for the Apple developer.   There are numerous shortcomings and missing features for Android devices.   That is odd since they tout the Android, Kindle, and Nook devices which are all distinctly non-IOS platforms.

It also seems as though there are a lot more “cant’ do that on the other platform” shortcomings with Corona than Cordova.   Yes, Cordova has issues as well, but there seems to be a much more concerted effort to get every feature in Cordova to work on all platforms.

Thus, Corona looks like a solid IOS development platform that *may* get some apps over to Android.  However, if you are going to build in what is almost an IOS only environment, why not just build with Objective-C?    Essentially Corona feels like a Lua-language alternative to Objective-C for people that find Objetive-C too hard to code in.    The cross-platform support still has a ways to go.

Posted on

Mobile Cross Platform Development : Cordova

Apache CordovaApache Cordova (aka Phonegap).

A little clarification on the name.  The NEW name will be Apache Cordova.   After Adobe bought the development firm that was working on Phonegap the Phonegap project itself was given to Apache Software Foundation to maintain its open source roots and continue development.  As of this writing the transition is still underway with MOST, but not all, elements haven taken on the Apache Cordova persona.

Our First App On Cordova

Our first app that we wrote using Cordova was the Abundascan application for Abundatrade.   The first release is a simple app that uses the camera to scan a barcode then sends the UPC to the Abundatrade server to get real-time prices that they will pay for used books, CDs, DVDs, and video games.    Functionally the app is simple and works well.    However one key element here is the primary reason we started with Cordova over other cross-platform tools like Corona, the camera.

Turns out that many of the cross-platform tools do NOT support the camera interface. That shot down Corona right away, which otherwise looked promising.

Cordova And Cameras

The nice part about Cordova is that the system is basically a wrapper for the native web browser.  That means coding in HTML5, CSS, and JavaScript.  It also has a number of third party plugins that hook native mobile functionality (via Java or Objective-C) to a JavaScript class.   In theory that sounds great.

Luckily there is a good camera scanner app that reads UPC,and other machine-enabled codes like QR, codes created by Google released in the ZXing project.  The ZXing applet is ported and ready to use for Cordova as a plugin.

Cordova Camera Caveats

The problem is that theory does not work out in reality.   The plugin for Android works wonderfully.  The plugin on OS-X, not so much.  Not surprising that a Google app talking through JavaScript to an Apple owned OS and development environment doesn’t work well.  Apple really does go through a lot of effort to put a stranglehold on their development pipeline.

The bottom line, we have yet to get the camera plugin to work on IOS4 or higher devices.   In theory the demo app works, but we’ve yet to see it on our iPod Touch or newer iPhones.

The Android Version of Abundascan is out, but we still are having issues with Cordova on IOS.

Our Second App

Our second app is a little less ambitious as it is testing the waters for a larger project.  This app is simply a screen that shows your current GPS location with exact latitude and longitude.   Where Am I Standing? is a free app that does just that.   To make it a little more interesting we wanted to add an info page with our name and logo and a little bit of graphic “window dressing”.

Again, here we ran into multiple issues.  This time noticeable right on the Android before we even attempted the iPhone release.    We want a simple app with no glitches yet there are several things that still aren’t right.  We can spend a good bit more time addressing in convoluted code to workaround quirky UI elements.  Others are as-yet un-fixable.

Technically it was easy & works well. Aesthetically it is NOT of the caliber I want it to be at.    As I dug deeper into this I uncovered a lot of hidden secrets about mobile app development and why 99.99% of these cross-platform tooks like Cordova fail.

The Compromises

Here are the “little details” that are compromises I don’t want to make.  I want to build QUALITY apps.  That means making them as perfect as we can, and this stuff is far from it:

Swipe Right / Left : I wanted to be able to simply swipe the main screen to see the info screen (“created by Cyber Sprocket”).     One swipe works, then it breaks.  This is a fundamental issue in the browser kit Cordova uses as the foundation for their solution.   Google developers refuse to address it saying it is “as designed”.

Vertical Page Scrolling : I don’t want ANY page scrolling, jitter, etc.   The pages are too “tall” and are scrollable if you swipe up or down.  This can be fixed but takes extra coding to do so.   What a pain.

Button Highlighting : Sometimes the highlights on the info/home buttons “stick”.  This is a built-in feature of jQuery Mobile and Cordova.  It is wonky at best.

Screen Hesitation: Even on a mid-range phone with just about the simplest app possible, sometimes going to the “info” page hesitates, same with going back to home.

Navigation History : Go to info, then back to home.   Each time you do this is adds to the “history”.  Do it a few times and your back button is loaded up with a bazillion loops of home/info/home.   Again, fixable with code (mostly) but why?

Summary

While Apache Cordova will help you build apps using technologies you likely already know like HTML5 and JavaScript, the implementation is far from simple.  Getting stuff to work on more than one platform requires extensive knowledge of all the quirks.  Like IOS requires a special onDeviceReady hook or it won’t even load properly.   The apps also feel “heavy”.    The UI is not responsive and, depending on the hardware, often misbehaves.

While Apache Cordova may be a great tools for building a functional prototype or possibly building corporate apps where users may value function over form, in my opinion Cordova is a compromise.

Yes,  you can probably build a well-polished UI.   But it takes a LOT of extra effort because you are hamstrung by the JavaScript/web interface.  Of course you can write custom Java or Objective-C hooks and/or make your own plugin, but isn’t that point to get away from native custom code?    You can also get around *some* of the quirks with a good bit more coding, but how you get around which quirks often requires intimate knowledge of the quirks for the particular mobile OS that is giving you problems.

I’m sure we can build quality apps with Apache Cordova, but this is not about CAN we do that, it is about what are the benefits of doing so.  From a business perspective there appears to be little gained here over a process that includes solid architecture, documentation, code design, and good old-fashioned cross-platform awareness and porting.

Posted on

Apple’s On Top & How They’ll Self-Marginalize

AppleApple Exceeds Exxon’s Market Cap

An article was shared on a discussion list I am a part of about Apple having the same market cap as Exxon.   I wasn’t forwarded the original reference, but I think this story can be attributed to Radio-Info.com.  The excerpt:

Apple was actually bigger during part of the trading day, while Exxon pulled slightly ahead by the closing bell. Do you realize what that means? Exxon has long reigned as the world’s largest company ranked by market cap (price per share times the number of shares). By the time 4pm rolled around, Apple was valued at $346.7 billion, about $1.5 billion less than Exxon. Apple (“AAPL”) gained $20.80 on the day to close at $374.01 a share. Remember that Steve Jobs isn’t just into making hardware – he wants to control a lot of the IP-delivered traffic going to those devices. Just try getting something new onto your iPad without going through iTunes or the App Store. Pretty soon, a lot of radio will be going through Apple devices

As one person commented, “they have done a master job at creating brand awareness through advertising”.  Agreed.   But I also think there is more to it than that.

The “Apple Look”

Bringing touch screen computing to the masses via the iPhone was a big risk & a huge payoff.  They executed that perfectly.   It was the first small form factor touch screen with a user interface that could be understood by non-geeks.  Combine that with the sleek Apple “look”, which was used as a marketing tool itself, and a superb run of advertising campaigns (as Randy pointed out) and Apple exploded back onto the market overnight.

IMO, a key element here was the pervasive “Apple look”.  From the hardware itself, to the graphics on the devices, to the product packaging, even to their stores.   The attention to detail on the brand appearance was far beyond anything before it.  It was something most mainstream consumers had never seen before, that sort of attention to detail was reserve for exclusive luxury brands most consumers never see.  Apple raised the ante on what it takes to present a quality consumer experience, recognized that fact, and leveraged it in their branding & awareness campaigns.

Genius.

Will History Repeat?

Now to see if Apple can stay ahead of the competition.   Their stranglehold on the proprietary elements of their platform & the tyranny of requirements to play in their sandbox suffocated them once before. They are showing signs of repeating history.  Many of the tech guys I know prefer open Android platforms for development.  The other 10% drank the Apple Kool-Aid and barely acknowledge the existence of any other brand.  The only reason most of these tech people do IOS (Apple) development first is market share, but that part of the story is changing rapidly.

My Prediction

My guess is that Apple will retain their stranglehold on their channels and will continue to irk the hardware and software developers that make the IOS platform so successful.   The Android marketplace will continue to refine their products, market share will grow, and eventually Android will become the “go to first” platform for developers.   Soon after it will be the go-to platform for consumers as well.

Maybe Apple’s cash position will provide the resources to save themselves. I’m betting they go from defining the market to becoming a reactionary company that starts bleeding a lot of that cash.   They’ll bleed cash pushing more & more advertising.  They’ll start pushing product development outside the box in high risk moves that won’t pay off.  They’ll start cutting prices and working the “loss-leader” angle.

Eventually Apple might relax their policies.  It will be too late and they’ll have tainted a large part of the developer channel.  Many development firms won’t come back to the IOS platform purely on principle.    Within a few short years Apple’s market dominance will once again be marginalized just as it had been in the early PC market.  They’ll again be representing 10% of various market segments.

I’m hoping this doesn’t happen, but Apple sure is showing their typical colors here.  Just look at the Apple v. Adobe fiasco.   When people see my Toshiba Thrive the FIRST QUESTION they ask is “does it run Flash”.   “Of course, it’s a Droid!”.

Sound Off…

What is your opinion?  Where do you think Apple is headed in the next 3-5 years?