While building an Android Studio app the build failed with aapt errors. The aapt part of the build started off with a libz.so.1 missing error. Turns out I had already installed the zlib library with yum install so libz.so.i already existed in /usr/lib64/. The problem was with the library path. That is easily fixed.
Put these commands in your ~/.bashprofile as well:
However the ELFs were not happy. For those that don’t know what an ELF error means, it has something to do with byte offsets and library file formats. Turns out it is a cryptic way of telling you the program is trying to load a 64-bit version of the library it needs instead of the 32-bit version.
The .i686 versions of the yum install kits are the 32-bit versions of the libraries. They are placed in the /usr/lib directory. Setting LD_LIBRARY_PATH helps the 32-bit dynamically linked executable find the proper link library.
Now on to building this Android app on my CentOS dev box.
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!
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?
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:
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.
The following features available for iPhone devices are not yet implemented, or fully implemented, for Android device builds:
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.
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.
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.
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
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 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.
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.
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:
– 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?
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.
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.
Charleston Digital Corridor invited us to speak at their “Fridays At The Corridor” event this morning. The presentation was an introduction into the world of mobile apps from a business perspective. Why should you do a mobile app, how to get started, and how to engage the development team. It was not an in-depth discussion but rather a chance to hit on some of the high points, the recurring topics we discuss when clients ask us to develop an app for them.
We finally got our first App Inventor mobile application built and are underway on our second app. Here are our first impressions of building an actual app.
First App – The Pat A Cat Tutorial
The initial tutorial went very easily, after the fight to get the development environment set up. The first application took less than 5 minutes to create and get working, even in a standalone packaged app sent to my phone. I glossed over the “pet a cat” tutorial then created it without referring to the docs. It was very intuitive.
Second App – Barcode Scanner
The second attempt was a basic prototype of a far more complex application that was created with Eclipse and the Android SDK combined with the open source Zxing project. The idea is to have a simple bar-code scanner that when it scans a valid bar code calls a URL for one of our client sites and returns back the price they will pay for a book, dvd, cd, or video game.
With the initial Eclipse based project we had a standalone and fully self-contained app on-line within a hour. It worked well for a prototype and provides all the elements we need for a full blown app. It has to be coded in Java and requires a coding background.
With App Inventor we have a few hurdles as outlined below.
Hurdle 1 : Separate Install of Zxing Required
The built-in scanner class requires a third party application, the freely available Zxing App, to be pre-installed on the phone. That means if you were to put this into production all of your users would be required to go fetch and download another app before they could use this app.
Hurdle 2: Checking/Launching Third Party Prerequisites
Maybe I’m missing it, but I don’t see a simple way with the drag & drop interface to check if a third party app such as Zxing is already installed when running my new test app. That means we will only be able to wait until someone tries to scan, catch the error (we have error catching abilities, right? We’ll need to look into that), and then tell them to exit the app and go install something else then come back.
There also does not seem to be any way to automatically launch a third party app other than the select few that Google App Inventor supplies. So that means not launching the marketplace and sending them a “search for zxing” command. Luckily we can launch a web browser with a URL, but that is not exactly the same.
Hurdle 3: Bundling Other Apps/Libs
The best solution would be to bundle the other app along with our app so that installing our test app automatically installs Zxing. Even better would be the ability to make it a self-contained component within our test app.
Test 2 Summary
All-in-all we could knock together a simple prototype of our new scanner app, but it would be a rudimentary version of the final app. Not being able to bundle Zxing easily and, even better, including the libs directly in our project, makes it hard to sell this as a consumer friendly application.
Of course this is a new IDE we are playing with here. Maybe all of this is possible for the expert App Inventor developer, but for a noob the methodologies are not readily apparent.
After a full day of playing with App Inventory, here are my initial thoughts. The environment is perfect for simple to somewhat moderate level applications. It is good for things like a basic toddler app or a simple limited use consumer app. It may even be able to do some more complex tasks.
It is not going to build something like Angry Birds. Not even close (I know, that is not really what this IDE is for, at least not yet). It also is going to be difficult to create anything that is not based on down-the-middle business forms or simple media interfaces. Showing pics, playing sounds, firing off the camera or phone apps… no problem. But trying to complex interactions with any of those devices becomes more & more of a challenge to the point that learning some Java and using a full blown IDE starts to make sense.
So for a casual mobile app hacker that wants to create some simple apps for their kids, themselves, or their business it is great. It is also a good prototyping tool. Heck, you can even create some marketable apps here with some effort. At some point you will outgrow the environment and will want to start learning Java. This is a great way to get a layperson interested in the craft of computer programming though, and even teach them the basic concepts of logic and device interaction along the way. A perfect 101/201 level class in application development.
The only problem for a large number of casual app hackers is that you may need a comp sci Phd just to get the environment setup. And therein lies the rub. Google App Inventor is obviously targeted squarely at non-technophiles, the layperson that has an idea and a little bit of computer coding knowledge, NOT a hard-core tech geek. Yet, as you may have noticed in my prior posts, just getting setup can be a trail in patience and computer expertise. Yes, I have a “talent” for making technology break… any of the guys on my team will tell you that, but I assure you I’m not the only person who will run into problems.
A promising start, and a great fit for the right people. We’ll probably use Google App Inventor for some of our own simplistic apps and definitely for more than one prototype. However, for prime time level A applications it is not there yet.
While you don’t need to know how to code in Java, you will need Java installed on your computer. Don’t worry, your computer probably already has Java on it. If not, it is usually a simple process to install or upgrade Java on your system. It is not any more difficult than installing or upgrading Flash. That said, sometimes getting Flash or Java upgraded and installed can be a challenge depending on your computer security settings, hardware, disk space, memory, and other unique factors that require you to hire a Comp Sci major just to get started.
Notes about App Inventory and Java…
Requires Java 6.
Upgrading (or intsalling) Java can be a challenge on some systems.
Get Java at http://www.java.com/inc/BrowserRedirect1.jsp?locale=en
Java Exposes It’s Ugly
Now that we have our Java environment up-to-date we can get started. Surf to your App Inventor login and launch the program. If everything is going well you can follow the Google tutorial and start creating your first app, a picture of a cat that will meow when clicked.
This is where things get ugly for App Inventor and Java.
There are 3 main parts to creating your App Inventor mobile app:
The App Inventory Palette – where you draw your interface by dragging & dropping components onto a mockup phone.
The Block Editor – where you drag and drop logic components using a puzzle analogy. In essence you are writing Java code visually.
The Phone – connecting your Android phone is your staging (or testing) environment to see how things really work when “glued” together.
All was going well. The palette came up, got the button, the photo, the MP3 file all in place. Got the phone connected and the PC loaded the device drivers for the HTC Incredible being used as the test device.
Ok… let’s start writing some code. Fire up Block Editor. And…
We get “Java Ugly” in full effect. While Java has some very cool things that deserve bragging rights, over a decade into its existence and it still retains the uglies UI contest hands-down. Not only do all default Java interfaces look like they were designed for a 1987 character based terminal, they are often less than helpful in helping you interact with whatever files, folders, devices, or web addresses you need to resolve a problem.
In my case the “command interpreter” that allows the App Inventor to talk to the phone cannot be found. The ugliness ensues:
Yikes. Welcome to 1987.
Fixing The Missing Blocks Command Directory
Turns out that I missed an important step before setting up my environment. Not only do you need to upgrade/install Java, but you also need a desktop program that Google App Inventor uses to communicate with the phone (among other things). The Windows version is here:
Next Problem : Windows And Google Not Playing Nice
The next problem we run into is that the Block Editor cannot talk to the phone. It just doesn’t see it. After reviewing the App Inventor setup program we learn that you should “not change the default installation directory”. Virtually every single app on my computer goes on my 500GB D: drive, NOT the default C:\Program Files directory. Wow. Really, “don’t change the default install location”. Back to 1987 I guess.
So we uninstall the application. Re-install it in the default place. All is good, right?
Well, not so fast. Now the Block Editor is looking in the original D:\ install location but it cannot find some of the necessary components.
Great. Copy all the components over from the C:\program files directory. Still not working. Uninstall and delete EVERYTHING. Reboot… we’ll be right back…
Windows Serves Up EPIC Fail
We’ll be right back, my butt. On the reboot windows decided my Windows account no longer exists. I was immediately greeted with a rather useless “The User Profile Service failed the logon.” message as soon as I tried to get into my Windows account on my local PC. Great. Off to safe reboot & finding the answer.
Now for the favorite part of my app development experience. REGISTRY EDITING.
Yup, that’s right. To restore my account back to normal I had to edit the windows registry. What fun. Luckily that is all it took and the instructions I found on the Microsoft Support site actually worked. If you ever need to do this yourself, make sure you sacrifice the requisite number of goats then follow this link:
Ohhh… wait… no devices found. The editor is open, but it can’t talk to my phone. The phone is in the proper USB debug mode. No communication with the device. Wonderful.
It turns out that the AppInventor_Setup_Installer executable that we downloaded (all 90MB) may NOT have the proper driver for the HTC Incredible phone, even though Google notes it as one of the phones that works with this development IDE. Now we need to go to the HTC site and find the right driver and try this all over again.
Just to make matters even more fun, there is no simple “HTC Incredible” device driver. However, even with the phone attached to my PC and visible as an external device, a visit to the Device Manager in windows shows it as an unknown device with a name like “ADB”.
Setting Up HTC Drivers for Windows
So here I am, no obvious HTC Incredible drivers. Some hints on the “Internet at large” indicate that the full blown 30MB HTC Sync application, WHICH I DO NOT WANT, will have a driver for the phone packaged up in there. I sure as heck hope it doesn’t mess with my already working perfectly Google Sync program that keeps my contacts, calendar, and email all perfectly in sync with the Toshiba Thrive table, HTC Incredible phone, and my Windows desktop. We’ll see.
For now, I sit and wait… going on 15 minutes now… for a 30MB file to be downloaded from what must only be direct via mainland China on the 宏達國際電子股份有限公司 (HTC Corporation in case you’re wondering) website. I’m on a 50MB/10MB line, but this is slow as heck. Must be getting interrupted by some goats, stray chickens, and a stray tank rolling over the fiber line before it tunnels it’s way under the Great Wall on the way to The States. Man this is slow. Guess I’ll go practice more guitar lessons while I wait…
Installation of the HTC Sync program got the drivers. Sadly I had to start the installation, let it install Adobe AIR, the HTC driver, and some other junk then cancel out right at the start of the actual HTC Sync installation. At least I got out of that.
Next.. maybe we can code our first app.
Not So Fast…
Wow, this sure is a LOT of work for a supposedly easier way to develop Android mobile apps. I had Java, Eclipse, the SDK and my first mobile app written the “old fashioned way”, you know… with CODE and an tried & true ID like Eclispe, done in much less time than the 4+ hours getting this setup.
My intention was to write a quick article on actually using the App Inventor IDE, yet here I am writing about how to setup the IDE and how to install drivers and how to debug a failed Windows login.
So much for quick & easy.
Hopefully the next article will be about actually creating a usable app with App Inventor. Stay tuned.
Google App Inventor is a service and development platform provided by Google to make it easier to create and deploy Android mobile applications. I am reviewing the viability of this platform now that the technology has matured a bit and is gaining more acceptance in the community. It appears this project may have some longevity, which is always a concern with any Google endeavor.
One of the risk factors of a service like this is that the provider can pull the plug at any time. As many companies have learned along the way, if you rely on a Google Labs project as a core part of any project you may well find yourself re-inventing and re-creating on relatively short notice. Google has a history of dropping anything they consider a failed project with little advance warning.
Terms of Service
Nobody ever reads this things. You should. Especially when it comes to basing your next big money making software product on a platform somebody else OWNS. That’s right, Google OWNS the platform. That means they can make changes that directly impact your ability to produce, update, and continue to sell your project. If you’ve got the next Angry Birds on this platform you really don’t want rely SOLELY on an external organization, even one that will seemingly be around “forever”.
Here are some notable items in the TOS from Google App Inventor:
4.2. Google reserves the right (but shall have no obligation) to pre-screen, review, flag, filter, modify, refuse or remove any or all Applications from the Service. Google reserves the right to directly take down any Application that violates these Terms, any applicable Program Policies, or applicable law or regulation.
In other words, Google can pull the plug on your project at any time for any reason and even stop your product from being listed in the first place.
4.4. You agree that Google has no responsibility or liability for the deletion or failure to store your Application and other communications maintained or transmitted through use of the Service. You further acknowledge that you are solely responsible for securing and backing up your Application.
If they do pull your project, oh well. You are on your own. You cannot sue them if your $5k/month revenue stream suddenly goes away because they pulled your app.
5.3. Except as provided in Section 7, Google acknowledges and agrees that it obtains no right, title or interest from you (or your licensors) under these Terms in or to any Application that you create, submit, post, transmit or display on, or through, the Service, including any intellectual property rights which subsist in that Application (whether those rights happen to be registered or not, and wherever in the world those rights may exist). Unless you have agreed otherwise in writing with Google, you agree that you are responsible for protecting and enforcing those rights and that Google has no obligation to do so on your behalf.
Unlike some other online services, Google does not get any ownership of the project you post on this service. What you create you own.
7.2. You agree that Google, in its sole discretion, may use the trade names, trademarks, service marks, logos, domain names and other distinctive brand features of your Application in presentations, marketing materials, customer lists, financial reports and Web site listings (including links to your website) for the purpose of advertising or publicizing your use of the Service. 7.3. If you create an Application to share with other users of the Service, you may determine with whom you share the Application and grant to such users a non-exclusive, worldwide, and perpetual license to perform, display, and use the Application.
While you retain ownership of your app, if you have the next runaway hit Google can leverage your brand awareness to their benefit. In other words if you create the next Angry Birds app, Google can promote the heck out if it in their marketing pitch for their service… “Joe’s Super Cool App was created with Google App Inventor” and plaster that message all over the place. I see no real downside in this, but it is something to be aware of in case you later think “hey, they should be paying me to use my notoriety” once you get rich & famous.
What Is App Inventor?
App Inventor is a project manager and web based IDE (integrated development environment) for Android mobile apps. Like most IDEs these days the App Inventor starts of by being a graphical design environment. You “draw” how you want the app to look first, then connect functionality later.
“Real” programmers don’t necessarily like this as it can allow for some very sloppy coding. It also allows programming “noobs” to get in on app development without understanding the design principles of creating sustainable applications. However it is a great way to start an application for a mockup or to create simple applications that don’t require complex process flows.
I am now off to create my first App Inventor app. Stay tuned for follow up articles on the Google App Inventor IDE.