Simply Advanced

Concentrate more on less. And start every day as a producer, not a consumer.

Check it out and let me know what you think! I believe the new layout has improved upon the previous complexity and has the potential for more idea submissions to us by actually having a call-to-action (CTA).

http://simplyadvanced.net/

ps – Eventually, I will better integrate this blog and the main site, maybe. Currently, people interested in this blog and interested in our regular Simply Advanced website are two mutually exclusive groups in my opinion. Though, I could use this blog to establish more credibility when there are potential clients looking through the website.

Last week, I did some background research into which was the best cross-platform mobile development tools. I looked over many different SDKs and have all my notes in my other blog post: http://blog.simplyadvanced.net/cross-platform-mobile-development-tools/

Today, I spent time installing both MoSync and Titanium. Then, I tried to create a basic “Hello, World!” program with them. These results have a clear winner.

Background:
I am running the free version of both programs on Windows 7 (64-bit). I only tested developing Android applications at this juncture. iOS development requires a Mac for both of them (also according to Apple licences: “can only compile and publish from an Apple device”).

MoSync:
Within five minutes of installing their MoSync SDK and Eclipse-based IDE, I had a sample app running on my Android (4.0) device and felt very confident it would also easily run on other platforms. There were no problems, I was pleasantly surprised. And, it’s very easy to see how to extend the samples. Tip: I used http://www.mosync.com/documentation/manualpages/getting-started-html5-and-javascript

Appcelerator’s Titanium:
First, the installation process took about 4 times longer and took many more steps than I thought necessary. The Android emulator didn’t want to run because Titanium installed itself in a sub-directory of “Titanium Studio” and couldn’t access the directory itself because there was a space in its name. So, I tried to run the sample application on my same Android device and after 30 minutes of “pre-compiling” it seemed that Titanium crashed (infinite loop). Titanium’s getting started guide: http://docs.appcelerator.com/titanium/latest/#!/guide/Quick_Start

Conclusion:
MoSync’s first impression is fantastic for developers. Users are able to see results very quickly.

Keep in mind, this was only a test in first impressions so far. Very important, but nevertheless, I will still be experimenting with both MoSync and Titanium as the summer goes on and be posting about my experiences.

~ Danial Goodwin ~

It’s been a great week at Google I/O this year. I’m always interested in learning more protips for creating awesome mobile apps. So, the Android Protips 3: Making Apps Work Like Magic was a great session.

The biggest topic of the session was “context isn’t important, it’s critical”. The idea is that depending on the situation, the app should be working in different ways.

This includes location-based services, activity recognition (running, walking, driving, biking).

Examples:
- If the user is driving or running, then they may not need an update to their news feed. But, they may need to update the user’s location more often.
- If the user is still and they turn on their phone, then they may want to see updates to weather or news.

This summer I’ll be experimenting with different cross-platform tools in order to be more efficient with my time. The development tools that I’m mainly looking at will create native code code for each platform that the app runs on. The biggest reason for this is performance and having a native UI that users are used to with their platform.

So, the collection that follows are my notes I took when researching many of different cross-platform tools.

In doing background research for the cross-platform tools, they are great for basic app creation. But, app can quickly become non-basic as soon as they start accessing native APIs that are only available for a specific platform. Some of the biggest pain points with the cross-platform tools may be integrating other open-source codes, using multi-touch, gestures, and native UI features/paradigms. But, there are cross-platform mobile development tools that help with those features.

A big note on using cross-platform tools to create native apps: It is not “write once, run anywhere” (WORA). The idea of creating these native apps is to maximize code reuse and/or provide a higher abstraction level for development. Up to 50-95% of the code you write can be reused depending on the type of app you are creating.

My Results:
These final choices I made are bias because I didn’t want to spend over $1000 for Unity3D. I don’t even want to spend $200 for MonoDroid/MonoTouch, but I will if I don’t care for the free options as follows. I chose these options mainly because of their documentation, sample APIs, developer communities, and active development. Both of the following are free up to a certain point, but because I am in academia I get to go a little further with the tools.
1. MoSync
2. Titanium by Appcelerator

The following I’m not trying the following until at mid- to late- summer likely (because of cost, it can wait longer…)
1. MonoDroid/MonoTouch: ($99 academic rate per developer, per platform) The regular Mono library is free, but it is just an open source implementation of the .NET framework. It does not include tools for integrating with iOS or Android. Both of these tools integrate Mono into them.

More Specific Notes: (I take a lot of notes directly in Notepad++/Notepad)

/* Cross-platform SDK */

- Mono (native app, C#) (open source): This is just an open source version of the .NET framework to be used anywhere, like in Apple and Linux OS. http://www.mono-project.com
  - Mono for Android (proprietary): Free version only allows small apps and no access to 3rd-party libraries. Lowest paid version is $199 per platform/developer. Academic cost is $99 per platform, per developer (http://support.xamarin.com/customer/portal/articles/177042-do-you-have-any-student-or-academic-pricing-)
  - MonoTouch (for iOS) (proprietary): <same above="" as="" info="">
Conclusion: Good if already have much code in C#, or prefer the .NET framework.
- Unity3D - high costs
- Marmalade (native app, C++) ($15 per seat/month;$149 per seat/year): http://www.madewithmarmalade.com/
- Rhodes (HTML/Ruby): Says native app, but seems to be web app with just a native UI. http://www.motorolasolutions.com/US-EN/RhoMobile+Suite/Rhodes
- MoSync (native app, HTML/JS w/optional C/C++ extensions) (open source | Free): Seems promising. Needs Mac for iOS publishing.
- Titanium by Appcelerator (native app, JS) (Free): Uses JavaScript mainly, but it is not a web app. It is translated to native code (but, a web UI ‘could’ be made instead of a native UI). Android, iOS, and web only.
- PhoneGap (web app, HTML/JS): Very limited, though has basic access to camera, contacts, some sensors.

Conclusion: For free, use possibly MoSync or Titanium. For paid, use Xamarin’s MonoTouch/MonoDroid ($99 per developer, per platform)</same>

Wikipedia also has a very long list of potential cross-platform tools to choose from. It may be helpful if you are trying to do more background research into the many different types of development tools that provide non-native code when compiling for different platforms.

I’ve been asked many times, “what size logos do I need to upload to Google Play’s Developer Console?” and “how many screenshots do I need to take?” So, here’s a post that I point people to that explains everything you need to know about uploading graphics to the developer console in order to have an app published.

A very important point to remember: These images that are uploaded are one of the main factors potential users use to determine if they want to download it or not. They may not even read the description if you have an ugly app logo. Invest wisely in a great logo (either time or money). Google Play also allows each app to have one YouTube video associated with it and appear in the description. This is a highly effective way of showing that your potential users want to use your app.

The first part of this post will give a walkthrough on how to upload the required graphics to the developer console and the second part will have more resources for designers.

1. Walkthrough

  1. Go to https://play.google.com/apps/publish/ and select the app that you want to add the graphic assets to. You may either have to click “All Applications” in the top left or “Publish an Android App on Google Play” if this is the first app you are creating (create a title and click “prepare store listing”).
  2. You should now be in the “Store Listing” section for your app of choice. Scroll down until you see “Graphic Assets.” The screenshots section should be the first graphic assets to add.
  3. Now, you can either drag the screenshots onto the “Add Screenshot” box or click the box and browse to where the image is located. A minimum of two screenshots are required before the app can be uploaded to Google Play.

  4. Scroll down a little more until you see “High-res icon”. This is the final required graphic asset that must be added before publishing. It should be 512x512px. See 4. Summary below to see more details.

2. Resources – Things change, so here’s a link to the official Google Play Design Guide that all developers, designers, and Android app publishers should read.

  • Android Icon Design Guidelines. Here’s some tips for designers to work more easily with developers. Designers, please follow these guidelines when creating assets for Android. It will just make things so much easier for developers. The biggest thing is to not have any spaces or capital letters in the file name.
  • All About Launcher Icons. Launcher icons are the icons that users see when they install the app; It is what they must click on to open the app. You don’t want your icon to be so bland that the user can’t easily distinguish it from the many other apps they have already downloaded.

3. Bonus: Google Play Protips

  • Google Play allows you to create localized versions of your graphics. Think about translating any descriptions and titles on your graphics to the other languages you support.
  • And always, do market research (or due diligence) to make sure that you aren’t trying to upload the same style icon/logo as another app. Your app will seem like the spammy one. You want to have a distinguished style to set yourself apart from others (but not too different). Check out the Android Iconography

4. Summary: Graphic and Image Assets

  • Screenshots (Two Required)
    • Allowed up to 8 screenshots for each different device (phone, 7″ tablet, 10″ tablet)
  • High Resolution Icon (Required)
    • 512×512, 32-bit PNG w/alpha. This is the icon that is shown to users in Google Play
  • Feature Graphic (Optional, but recommended)
    • 1024×500, 24-bit PNG no alpha
  • Video (Optional link to a YouTube video, recommended)
  • For more information: https://support.google.com/googleplay/android-developer/answer/1078870?hl=en

I hope this helps.
~ Simply Advanced ~

First of all, if you have never created a Google Play publisher account, then see: http://developer.android.com/distribute/googleplay/publish/register.html

That link above will walk you through the steps necessary to be able to upload apps on Google Play and start making money from them.

When creating a new account you will have to go through a few easy steps and pay $25 to setup the account. Then you should appear at a screen that looks like the following:

Google Play Developer Console Home Screen

The options are self-explanatory. But, the first thing that you would probably want to do is set up a merchant account in the bottom-right. This is how you will be able to accept in-app purchases and create paid apps. The second step for you probably (if you aren’t a developer) is to invite co-workers to the developer console in the bottom-left. This will allow you to invite by email your developer to upload the Android APK (app packages that users download and install on their device). You can also invite your graphics designer so that they may upload all of the required logos and screenshots. And either yourself or a copywriter can fill in the app description and promo description.

I will eventually create more posts that explain exactly how to perform each of the roles for the developer, designer, and copywriter. I know how to do each of these because of the many Android apps that I’ve successfully published. If you are also doing each aspect of the app publishing, then I highly recommend reading http://developer.android.com/design. There is a lot of highly useful information there. But, don’t limit yourself to just that one great resource. It takes a lot of knowledge to have a highly successful app.

During the session, the speakers talked about how to convert an Android app to a BlackBerry compatible version. Here’s some quick notes that I took during the session:

Easy to use Android runtime on BlackBerry BlackBerry 10.2 and 10.1 roadmap Open source Android 2.3.3 Apps are indistinguishable from native apps. Repackaging an android app can take as little as two minutes. Update runtime scheduled for the future. Moving to jellybean 4.2.2 in the future. 10.2 Beta released in June. Full release in August. Automatically integrates with BlackBerry 10.2 Gestures have been incorporated into the runtime. About 70% are currently compatible. Not all android apis are supported. Can only be used on the personal perimeter. Still download able through BlackBerry world. Maps API not supported. Recommends webview. Open Street Maps supported. Repackage APK to BAR format. Online packager available at BlackBerry developer site. Runs on the browser. Use the BlackBerry simulator to test apps. Should be able to call an outside email client, dialer, or calender without any issues.

Bottom line: nothing extra is required to port to BlackBerry. Runs Android natively. Just requires submission to BlackBerry World.

At Google IO’s keynote this year, the biggest announcement was the unification of Android and Chrome services. I’m going to make a quick prediction of the future of Google’s services.

By this time next year, Google will announce that Android OS will be fully integrated into Chrome. Just like Google Glass extends Android experience on the phone. Chrome on computers will be able to extend the Android experience.

I wouldn’t be surprised if Google eventually rebrands Android to be Chrome, this would be about 3-7 years down the line. I’m leaning towards the 2-3 year mark. They may even combine both of the names to one integrated product name.

Have you noticed that many Android features have been getting integrated into Chrome? Slowly, but surely, Google’s Chrome browser will be able to offer all of the services that Android offers.

Larry Page during the keynote also quickly talked about unification of writing code once and having it run on many different platforms.

When it was announced a few years ago that Google would make laptops and netbooks, many people (including myself) thought the operating system would be Android. But, instead, Google chose to integrate just Chrome to become Chromium. That was great at a time where speed and power mattered and they could easily distinguish themselves in those regards. Speed and batter-saving will always be important, but they won’t always be the attributes that separate devices and brands. Now, it’s time to think about what is the distinguishing factor going to be when everybody has ultra-fast boot/startup times and ultra-efficient operating systems. App availability and features will always be important also, but it’s distinguishing factor will go away as cross-development tools get more and more developed and easier to work with.

As I’m writing this, I’m going to mention some more ideas that came to mind that the far future holds. These ideas may be a little far-fetched, but I like writing about them anyways.

Unfortunately, I see content creation as just a phase in our human social lives. Currently, the trend is still going up. Many cool new services and features are being offered that make it too easy to create content. Eventually, it will go down. I’d say we’re about 30% through the bell curve. As content creation starts to go down, content absorption will still be going up for a little while longer, then it will also go down. This will be the point in time when people learn that they don’t need to learn everything and can just access it in the computer connected to them. Our society as a whole will seemly get smarter and smarter. There will be no need for content creation or absorption at this point. Parallel to what I have mentioned so far, I imagine our world to become more data-centric as a bell-curve also. We are about 1-5% through this bell curve. Many more people will want the ability to track themselves: how they exercise, run, how they sleep, and how they learn. The later being the biggest/greatest one. As people learn all this amazing stuff about themselves, algorithms will learn the habits of the many and will soon be able to apply metrics automatically and there will be no more use to collect data about oneself because there will be nothing else for them to learn.

– Danial Goodwin -
Think. Do. Learn.


When trying to import some sample code using Android’s BackupManger, I received the following error.

The import android.app.backup cannot be resolved

I was really surprised that a search for that specific string didn’t return anything, so I found out the answer myself.

BackupManager for Android was added in API 8 (2.2). So, when the android:minSdkVersion is lower than 8, this error will show. After making sure the android:minSdkVersion is at least 8, Eclipse may not automatically change the project.properties file to represent the same thing. My problem was that in project.properties, there was target=android-4, instead of the target=android-8. You’ll need the later in order for the android.app.backup.BackupManager to be found.

Have you gotten these errors?

[2013-04-03 00:00:00 - Dex Loader] Unable to execute dex: GC overhead limit exceeded
[2013-04-03 00:00:00 - OsmAnd] Conversion to Dalvik format failed: Unable to execute dex: GC overhead limit exceeded

I have a few times now and decided to learn how to fix it. The error is caused by Eclipse not having enough memory for large projects.

Solution:
Change some values in your Eclipse.ini file. This file is located wherever you downloaded Eclipse. If you don’t know where that is, then check your Downloads folder. Depending on which version of Eclipse you are using, the folder may either be called something like “eclipse-mobile-juno-SR1-win32-x86_64″ or “adt-bundle-windows-x86_64-20130219″, if you didn’t already move the eclipse folder from within it.

When you open Eclipse.ini, you should see something like:

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.200.v20120522-1813
-product
com.android.ide.eclipse.adt.package.product
--launcher.XXMaxPermSize
256M
-showsplash
com.android.ide.eclipse.adt.package.product
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.6
-Xms512m
-Xmx1024m
-Declipse.buildId=v21.1.0-569685

Change the two values at the bottom to something like the following and you’ll be better off. Just restart Eclipse for the changes to take effect.

-Xms512m
-Xmx1024m

Source: http://docs.oseems.com/general/application/eclipse/fix-gc-overhead-limit-exceeded