Planet Android

Android Apps: Say Hello to My Little Friend : Huawei Ascend P6 Goes Live

Chris — 2013-06-18T23:38:12+00:00

Well, the Huawei Ascend P6 is not so little after all, don't be fooled by the title, it's actually a high end device from a company whose name I stopped trying to pronounce some years ago.

XDA Developers: Forum Added for the Samsung Galaxy Mega

Will Verduzco — 2013-06-18T23:00:18+00:00

What do you do when the Galaxy Note line is simply not big enough? You get the Samsung Galaxy Mega. And what have we done for those who have found themselves in such a spot? We’ve given them a forum, of course.

To say that the Samsung Galaxy Mega is a large device is no understatement. Samsung’s large slate-style phone has a screen measuring in at a whopping 6.3 inches. The device has a 1280×720 resolution, yielding 233 ppi. The device is powered by a 1.7 GHz dual-core Qualcomm Snapdragon 400 SoC featuring the Krait processor and Adreno 305 graphics. It also features 1.5 GB of RAM and either 8 or 16 GB of storage. The Samsung Galaxy Mega comes preloaded with Android 4.2.2 Jelly Bean and is encased in a plastic enclosure measuring a mere 8 mm thin and weighing just 199 grams.

Is this your next device? What do you think about its screen size? Let us know in the comments below. And if you’re itching to learn more about the device, be sure to head over to the newly created forum to get started.

Android Apps: Samsung To Launch First Tizen Smartphone Based on Exynos 4

Chris — 2013-06-18T23:00:01+00:00

Tizen is Samsung's own mobile operating system, in case you never heard of it, it's not a weird Asian dish or anything.

DroidGamers: Like the Where's My series from Disney? Mickey will be joining the crew shortly

AndrewH — 2013-06-18T19:35:40+00:00

Disney's Where's My franchise has a new installment heading its way any day now. Currently there is Where's My Water? and Where's My Perry? and shortly we will have Where's My Mickey? being added to that list. As you are probably guessing, this particular addition to the franchise is based off of the Disney Television Animation's Mickey Mouse Cartoon Shorts.

This new installment into the series will feature 100 levels spanning across five different episodes for you to work your way through. Along with all the new levels there also happens to be new game mechanics as well that pertains to the weather in the game. You'll have to use wind, clouds and rain to get through some of the levels.

Other Where's My Mickey? Features include:

• A Whole New Look -- A classic Mickey art-style with a contemporary touch, inspired by Disney Channel's new series of Mickey shorts
• Collectibles and Bonus Levels -- Help Pluto look for hidden collectibles to unlock more bonus puzzles
• Featuring Mickey and Friends -- Discover more hilarious episodes and new friends, beginning with Goofy

When the game launches it will be available for download for free where you'll be able to try out six of the Goofy levels. After that if you want to continue on with the game you'll need to unlock the full version through a one-time IAP. While the video trailer says the game is available now, it hasn't appeared just yet. Some other sites are reporting that it'll arrive for iOS on the 20th of this month so we should see it sometime between now and June 20th, 2013 on Google Play and Amazon's Appstore.

Website Referenced: Disney's YouTube

AndroidPIT: HTC Desire 200 is here: Lower end device with high aspirations

Sterling Keys — 2013-06-18T19:26:05+00:00

HTC has thrown another competitor into the ring of the low-to-midrange smartphone market with their HTC Desire 200, an entry-level device with a 3.5-inch screen. While not everybody is looking for the latest or the greatest (….or just don’t want to drop several hundred dollars for a top of the line phone), there’s still quite a market for something like this.

The brand new HTC Desire 200. / © htc.com

(This is a preview - click here to read the entire entry.)

DroidGamers: Phosphor Games drops the price of World War Z down to $0.99 for a limited time

AndrewH — 2013-06-18T19:15:14+00:00

Phosphor Games and Paramount Digital Entertainment have decided to temporarily drop the price of their newest zombie survival movie spin-off game World War Z. What was once $4.99 is now a mere $0.99 for a limited time. So why the sudden sale right after Father's Day?

Our guess is that since the game has suffered from some bugs, bad performance and just generally angry reviews from people who purchased the game right away, they decided to drop the price of the game in order to help get more people to purchase it. Apparently the game received an update today when it went on sale but no changelog was posted. This means it was probably just a bunch of bug fixes.

Some people seem to be able to play the game just fine though and the update probably helped with that. If you've been wanting to pick the game up, now would be the time to do it and save yourself four bucks in the process.

Google Play Link: World War Z

AndroidPIT: Sony Xperia Z gets the Yankee Treatment

Sterling Keys — 2013-06-18T18:46:35+00:00

Well, after being able to only read about the Sony Xperia Z for some time, it looks like it Sony’s new flagship device will be hitting the North American content in the coming weeks. T-Mobile has confirmed that it will be the carrier of choice in the United States for the Xperia Z.

Welcome to the U S of A, Xperia Z. / © AndroidPIT

(This is a preview - click here to read the entire entry.)

LandOfDroid: My Little OPPO Rant

John McKenzie — 2013-06-18T18:33:09+00:00

You know I like OPPO, I like the way they seem to just listen but sometimes I think they just get ahead of themselves by doing whatever people want:

Take this image posted on their Facebook page as an example. It leads to a discussion forum where fans of the device suggest to the company that they should do a Google Edition.

Now, a lot would need to happen for this to become real. You can’t just stick Android 4.2 on a device without customisation and suddenly start calling it a Google Edition, if that were the case then all of the no branded tablets and handsets would also be “Google Edition”.

There’s a reason HTC, Samsung and Sony (Motorola too perhaps) have created a device which can run a Google Edition, it’s because they’ve put in work to speak to Google and arrange for it all to happen as well as having their software and hardware teams work with Google to get the device talking to the right OTA servers etc…

OPPO, if you want to play with the big boys, start acting like a big boy and stop being bullied by your friends (consumers) into giving them everything they want, especially when it’s not something you can deliver “just like that”.

XDA Developers: Voice Control Your Phone with Tasker and AutoVoice – XDA Developer TV

Jimmy McGee — 2013-06-18T18:30:04+00:00

XDA Developer TV Producer Kevin set up his phone to respond to his voice. He does so with Tasker and some other programs like SMS, my Car and Me, AutoVoice, Secure Settings, and Gravity Screen Off. Earlier, Kevin showed us advanced Uses, intermediate uses , and basic uses of Tasker. Then, Kevin showed you an alternative to Tasker called Llama. He covered the basics then expanded on them.

In this part of the series, Kevin gives you what you asked for. Kevin shows you how to control your phone with your voice. So check out all the videos in this Tasker series, and make your phone work for you. What are you waiting for? Check out this video.

Be sure to check out other great XDA Developer TV Videos and Kevin’s other videos.

Important Links:

Check out Kevin’s YouTube Channel.

Check out the new Sony Xperia Tablet Z at the Sony Store and check out Sony’s YouTube Channel.

Swarm: Try Your Skills And Reflexes With Paddle Master

Beti — 2013-06-18T17:00:00+00:00

Fans of classic "Pong," along with those who have never heard of such will love Paddle Master for Android. The game is reminiscent of the old school game of yesteryear, but with some very modern differences that make it perfect for old and young alike. Simple enough to qualify as a brain vacation, yet challenging enough to keep players occupied for hours, it really is the perfect addiction for everyday life.

There are two balls and curved paddles for more challenging play and better control. There are 8 possible power ups with effects lasting for several seconds, and you can play against the device or other players. You only score with your ball color, and to keep things interesting the balls go faster when they hit the walls. For even more fun, there are 8 unlockable levels. When the balls hit each other a ring drops, and if you catch the ring with your ball it is yours. Rings unlock new levels, so they can be quite valuable.

Post scores to the Swarm leaderboards for even more fun. You can see how you rank against players worldwide. This can offer encouragement to keep trying, adding an element of competition, or you may find yourself fighting to defend your top spot. Either way, with the perfect mix of old school and modern, you'll have a blast playing whatever your age.

Android-Games: Shoot A Ray releases Pulse Infiltrator for Android

Adam Field — 2013-06-18T16:44:41+00:00

Shoot A Ray releases Pulse Infiltrator for Android

E3 may be over, but new Android games are still rolling out like Pulse Infiltrator from Shoot A Ray. It’s a first-person shooter that describes itself as a tactical espionage game, and if that doesn’t sound cool enough for you there’s also telekinesis…

Android Games

LandOfDroid: The Quest for Addtional Power -v- Reduced Functionality

Glenn Blair — 2013-06-18T16:07:29+00:00

Recently I have started to think today about Battery Life v Functionality. I have seen numerous cases of people who seem to be willing to completely cripple their smartphones (at least what I deem as crippled) in order to get what is likely to be just an extra few minutes life out of their phones.

At what point does restricting the functionality of a product depreciate the product itself? At what point would you actually just be better off using a tablet and a Nokia 3310?

I use my phone pretty much how Google intended and I am never so desperate for extra juice that I turn key services off.

Others however run their phones extremely limited. They do not run any auto-sync (talking Gmail, social networks, widgets etc) they have brightness on minimum not auto, they turn power save modes on (where available) which can really slow the CPU of the phone down and they even turn off extra services like Google Now and Location reporting.

I couldn’t imaging running my phone without data on all the time, without location reporting, without push notification in real-time from all my key apps.

In-fact f I had to manually do this I imagine my battery usage would increase as I would be looking at the phone more often in order to ‘refresh’ the items rather than only looking when it has something to show me.

I get an average of 20-24 hours battery life from all my devices with around 3 hours screen on time, with GPS, bluetooth, mobile data and/or wi-fi running all the time, I am not willing to compromise key functionality just to get an extra little bit of screen on time, certainly not for day-to-day use. Why should I spend upwards of £500 on a top of the range device just to turn it into a device equal to one that costs £50?

We would love to hear your thoughts on this, if you use Google+ then simply comment below

Coderz Heaven: We are Moving………

James — 2013-06-18T05:24:53+00:00

Hello all……

We are moving on to a faster server… So if you experience any difficulties please bear with us and inform us.

Thankyou

Mutual Mobile: Weekly Mobile News Roundup: June 17

Becky White — 2013-06-17T16:30:49+00:00

Last week, Apple held its annual World Wide Developer’s Conference. We dive into some of the biggest announcements: a groundbreaking new “flat” redesign in iOS 7, new Macs, iOS for cars, and more.

News and Insights

Apple Debuts iOS 7, OS X Mavericks, and New Macs: Everything You Need to Know – The Verge

All the top news from WWDC, in one place.

Cook Unveils Mission Statement, iOS 7 Gets Colorful, New iPhone – Forbes

A few of the things that happened around Apple this week.

How Apple’s iOS 7 Changes Everything For App Designers – ReadWrite

Everything app designers know has been tossed out the window..

Why iOS 7 Looks Unfinished (Spoiler: It’s Because It’s Unfinished) – TIME

A collection of top mobile analysts’ thoughts on the new OS.

Why Do Super-Elite Customers Get All The Attention? – Forbes

How to use big data and mobile to delight both the “super-elite” and regular joes.

With Wearable Tech, Human Behavior is Now a Design Problem – GigaOM

Wearable devices will be able to influence our behavior in ways both good and bad.

Saks Deploys 2,000 iPads in Stores, to Launch OFF 5th Website in Fall – RIS

Saks’ multi-channel shoppers spend 3-4x what single-channel shoppers spend.

Mobile Marketing Isn’t About Screens or Devices, It’s About Behavior – AdAge

Consumers move fluidly across devices and platforms; brands must do the same.

Research

[Infographic] Mobile at WWDC – The Push

The buzz, the snark, the hits, and the misses from Apple’s annual conference.

A Day in the Life of a Mobile Consumer – Flurry

How consumers are using apps throughout the day, and how it relates to wearables.

82% of eCommerce Merchants Not Tracking Mobile Sales – Mobile Commerce Daily

The majority of merchants don’t know whether a purchase comes from mobile or PC.

One-Third of Americans Now Own Tablet Computers – New York Times

The fastest-growing segments: affluent households, college graduates, parents.

Smart Mobile Devices Account for Small Share of TV Viewing – eMarketer

Only 2% of total TV viewership occurred on a tablet or smartphone.

The post Weekly Mobile News Roundup: June 17 appeared first on Mutual Mobile.

Mark Murphy: Calling for More Android Developer Support Sites

Mark Murphy — 2013-06-17T11:09:21+00:00

About seven months ago, I launched AndGlobe, a site to collect the names and links to Android developer support sites. Here, “support sites” are defined as forums for asking questions and getting answers.

In particular, AndGlobe is designed to highlight sites that offer support in languages other than English. Android development has gotten too large to expect everyone trying to write Android apps to have as solid of a grasp of English as they do Java.

Non-English support sites help in two ways:

They provide a place for non-native English speakers to ask questions in a language that is more comfortable for them, resulting (hopefully) in better questions and better discussion to refine and answer those questions.
For questions that one of these communities cannot answer on its own, the community can serve as a “springboard” for asking the question elsewhere, such as on StackOverflow. If desired, the community can, in effect, ask the question elsewhere, pooling their skills in other languages, rather than necessarily limiting it to the skills of the original person with the question.

So far, AndGlobe has links to 19 non-English support sites, which is wonderful. However, the language range could use more breadth. For example, I have no links to sites in languages native to Korea, China, or India, and I have only one Japanese-language site. I have no links to sites in Arabic, and only one in Hebrew. I have some Russian sites, but little else from eastern Europe. And so on.

Please, if you know of question-and-answer Android development sites, beyond the ones already listed at http://www.andglobe.com, let me know about them! As is outlined on the GitHub repo for this data, there are several ways to send me updates:

Send a GitHub pull request
File an issue with the language, name, and URL
Send an email to globaldev@commonsware.com with the language, name, and URL

According to industry analysts, sometime in 2014, there will be more Android devices in use worldwide than Windows machines. A global user community needs a global developer base, and a global developer base needs multi-lingual developer support.

Thanks in advance!

Android UI Patterns: Dont's of Android design

Juhani Lehtimäki — 2013-06-17T09:01:51+00:00

Android app development frameworks is good, really good. It is very flexible and allows devs to do nearly anything they want. The flexibility extends to design as well as developers are able to implement crazy designs make the apps work. But! Not everything is worth doing. Often, the components provided by the framework are better. They look better, feel better and users know how to use them.

Here are few tips about components that are better left alone than reimplemented. Things not to do in Android app design / development.

Re-skinning everything

Some designers are in an opinion that if any part of an original app theme is visible the app is not designed. Re-skinning every single component on Android is not necessary. While well re-skinned apps might look great and even feel like part of the platform it definitely adds a massive amount of work for bot designers and developer. It simply isn't worth it. Start your design from Holo theme and change things you need to change and leave components that work fine without changing stock.

Badly re-skinned apps are disasters. These apps don't feel like they are meant to be used on Android. Take a look at the screenshots below. This app is over designed. Every single component behaves strangely and looks strange. Don't do this!

Take a look at the building blocks Android provides you and use them as much as possible. Some good examples of right way styled apps are Player FM and Pocket Cast.

2.3 / iOS style tabs

Tabs in Android apps are very identifiable and stylish by default. Don't bring other platform tab design to your app. This is one of the quickest ways to make sure that your users will have a very bad first impression of your app. Never do this!

Take time to familiarise yourself with the way Android apps use tabs. The default tabs and interaction with them is very well thought out. Users expect then to work similarly they work in other apps.

Not only do the framework tabs look great but using them gives you a lot of features for free. Remember that tabs on Android should be swipable. They should also adapt to wider screens by moving them to the action bar if there's room. This saves a lot of vertical space when user uses the device in landscape. They are also easily stylable. You can change all the colours to match your brand. Try Google IO app to see how Android framework tabs work (and are expected to work).

Non-standard action bar

Action bar is one of the key UI components of most Android apps. There are apps that don't need to have an action bar but most apps do. Follow the design guidelines with action bar! Do not try to reinvent the wheel. Action bar has multiple function. It gives user context information, helps with navigation, helps branding the app and provide access to most important functionality of any screen.

If your app uses a title bar consider using an action bar instead. Your app will instantly look like it belongs on Android.

By including an action bar to your app you'll save considerably in design as many design decisions are already made (and tested!) for you. You'll also save a lot of time in development phase. Any apps targeting Android 3.0 or newer can use the action bar implementation directly from the framework and if you want to support older apps ActionBarSherlock is a great library for you. The ABS library gracefully steps aside when the app runs on a device that has action br support and therefore apps behave exactly right on newer platforms as well.

Rounded text containers, boxed text fields and list carets

Panel backgrounds with shadows and rounded corners simply don't belong to Android. Do this and nobody will believe that you or your designer knew Android platform (DB app below).

Another simple thing that is to be avoided is right carets in tappable items when there's clearly no confusion that they're tappable (UEFA app below). These things don't add any value in most cases. If you have a homogenous list of items that are all tappable that's what users are going to do. Just drop them from your design and your app will look better.

Boxed text fields are the past (BMW Drive now below). Try to avoid using them in your apps. Seeing text fields like these in apps immediately makes your app feel like it was designed years ago.

Quick actions replacing content

Quick action menus which replace the content when opened are bad user interface design. There's a very simple reason why: you don't want to hide the target of the contextual actions! I don't understand why Twitter is doing this. It does not make any sense! dont' force users to remember which line they selected.

Use the selection mode in action bar instead. This way users see what they're doing. It's simple and elegant solution. Users will see which items they're manipulating and there's much lower risk for mistakes.

Apps that feel like a website

Web apps belong to a browser. Make your app a native app and ignore hybrid tools like PhoneGap and don't wrap your website into a WebView and release it to Google Play. Cross-platform frameworks promise a lot of savings as you can write an app once and run it on iOS and Android or they promise that you can use your web development skill to build apps. In the long run these tools just harm your brand and waste your time. So many developers have moved from these tools to native development after first wasting months trying to build something acceptable and finally realising that PhoneGap and other tools like it simply produce garbage.

Take the time to learn native. If your project does not have budget to build a native Android app build a proper web app and keep it as a web app and build an Android app once the budget is found. Web apps are great but wrapping them as apps is just stupid.

Galaxy Tab Review: Galaxy Tab 8.9: Download Android 4.2.2 CM10.1

Galaxy Tab Review — 2013-06-15T15:17:05+00:00

Samsung did not sell a lot of Galaxy tab 8.9 tablets and due to that it never released Android 4.2.2, let alone Android 4.1.1 jelly bean for it. XDA is here to rescue and they were able to get everything working except for HDMI output. Even the keyboard dock works with it. This is a [...]

The post Galaxy Tab 8.9: Download Android 4.2.2 CM10.1 appeared first on Galaxy Tab Reviews, News, Updates.

Mutual Mobile: Mobile Minute: June 13

Kaely Coon — 2013-06-14T22:29:50+00:00

For consumers, mobile payments offer low-friction checkout. For retailers, it’s an easy point of sale system. So why haven’t mobile payments taken off? Starbucks is the surprising current leader, generating more than 3 million in-app transactions per week.

That’s a huge number. Especially when it comes from a coffee company, rather than a payment platform. What should marketers learn from them?

Starbucks has put mobile first, building loyalty with customers through an efficient, elegant way for them to pay — essentially with a digital gift card that users love. Brands can learn from Starbucks, blending easy payments with loyalty perks.

If used smartly, mobile payments create a big opportunity to enhance the brick and mortar experience.

The post Mobile Minute: June 13 appeared first on Mutual Mobile.

Chet Haase: DevBytes: Animating ListView Deletion

Chet Haase — 2013-06-14T21:06:00+00:00

It's Friday: must be time for another DevBytes episode.

Finally, here is the DevBytes episode around the ListView animation demo in the talk A Moving Experience that I gave with Romain Guy at Google I/O last month.

The code is nearly the same as that in the I/O talk, except I tweaked it to make it more general-purpose. Specifically, it no longer depends on the setHasTransientState() method (introduced in Jellybean 4.1) to keep the views around while fiddling with layout. Instead, it uses an adapter with stable itemIds, and uses those Ids to track where the content is before and after layout.

As written, the code is still dependent on Android 4.1, but that's only because of the use of ViewPropertyAnimator.withEndAction() method, which is really just syntactic sugar around adding a listener and running the end-action code in the onAnimationEnd() callback. So you could totally port this code all the way back to Android 3.1 (when ViewPropertyAnimator was introduced) or even 3.0 (if you use ObjectAnimator instead).

Watch the video. Check out the code. Play with ListView. Animate. Enjoy.

A Moving Experience: http://www.youtube.com/watch?v=ihzZrS69i_s

DevBytes on YouTube: http://www.youtube.com/playlist?list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0

Code: http://developer.android.com/shareables/devbytes/ListViewRemovalAnimation.zip

Android-Games: The Official Man of Steel game Soars onto Google Play

Adam Field — 2013-06-14T15:45:05+00:00

The Official Man of Steel game Soars onto Google Play

Yesterday we covered Gameloft’s Despicable Me Minion Rush, and today we’re back to take a look at another movie tie-in game with the Man of Steel.

Android Games

Swarm: Swipe Your Way With Swipebox

Beti — 2013-06-13T21:05:00+00:00

Looks can be deceiving, and that is exactly the case with Swipebox for Android. This is a simple swiping game, but the puzzle twist adds a level of difficulty that can challenge even the most seasoned player. There is no fear of boredom here, as just when you think you have it figured out the game changes on you. The name of the game is points, and you can gain bonus points for swiping certain color combinations, up to 10 bonus points to be exact. However, there are forbidden combinations as well, and those can cost you 30 points, so beware!

For every 150 points you gain the game speeds up, making it more difficult as you go, and just when you have the pattern figured out at around 75 points earned, the pattern changes. If this isn't enough to keep you jumping, you can always post your scores to the Swarm leaderboards for some friendly competition. The online leaderboards let you share and compare scores with players worldwide. See how you stack up, and fight to make it to the very top.

This is the perfect game for killing some major time or just passing a few minute while you wait for something. Great for all ages, the challenge is real, but so is the fun.

Coderz Heaven: Use of custom animations in a FragmentTransaction when pushing and popping a stack. or How to apply animations in Fragments when pushing on to a stack?

James — 2013-06-13T17:01:50+00:00

Hello all

We have seen many examples of how to use fragments in android.
You can search coderzheaven for all types of transactions using Fragments.
Today in this post we will see how we can apply animations to Fragments when pushing on to a stack.

This is fairly a long example. I will try to explain with code one by one,
You can click on the download link to get the source code.

Here we start.

At first we will see the layout used in the Fragment.

hello_world.xml

<?xml version="1.0" encoding="utf-8"?>
<TextView xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/text"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:gravity="center_vertical|center_horizontal"
    android:text="@string/hello_world"
    android:textAppearance="?android:attr/textAppearanceMedium" />

Now the layout for the activity.
fragment_stack.xml

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:gravity="center_horizontal"
    android:orientation="vertical"
    android:padding="4dip" >

    <FrameLayout
        android:id="@+id/simple_fragment"
        android:layout_width="match_parent"
        android:layout_height="0px"
        android:layout_weight="1" >
    </FrameLayout>

    <Button
        android:id="@+id/new_fragment"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_weight="0"
        android:text="@string/new_fragment" >

        <requestFocus />
    </Button>

</LinearLayout>

Now the xml for the animations in the Fragment.
First create a folder inside res folder called “animator” and create four xml files inside it.

fragment_slide_left_enter.xml
fragment_slide_left_exit.xml
fragment_slide_right_enter.xml
fragment_slide_right_exit.xml

fragment_slide_left_enter.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android">
    <objectAnimator
        android:interpolator="@android:interpolator/decelerate_quint"
        android:valueFrom="100dp" android:valueTo="0dp"
        android:valueType="floatType"
        android:propertyName="translationX"
        android:duration="@android:integer/config_mediumAnimTime" />
    <objectAnimator
        android:interpolator="@android:interpolator/decelerate_quint"
        android:valueFrom="0.0" android:valueTo="1.0"
        android:valueType="floatType"
        android:propertyName="alpha"
        android:duration="@android:integer/config_mediumAnimTime" />
</set>

fragment_slide_left_exit.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android">
    <objectAnimator
        android:interpolator="@android:interpolator/decelerate_quint"
        android:valueFrom="0dp" android:valueTo="-100dp"
        android:valueType="floatType"
        android:propertyName="translationX"
        android:duration="@android:integer/config_mediumAnimTime" />
    <objectAnimator
        android:interpolator="@android:interpolator/decelerate_quint"
        android:valueFrom="1.0" android:valueTo="0.0"
        android:valueType="floatType"
        android:propertyName="alpha"
        android:duration="@android:integer/config_mediumAnimTime" />
</set>

fragment_slide_right_enter.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android">
    <objectAnimator
        android:interpolator="@android:interpolator/decelerate_quint"
        android:valueFrom="-100dp" android:valueTo="0dp"
        android:valueType="floatType"
        android:propertyName="translationX"
        android:duration="@android:integer/config_mediumAnimTime" />
    <objectAnimator
        android:interpolator="@android:interpolator/decelerate_quint"
        android:valueFrom="0.0" android:valueTo="1.0"
        android:valueType="floatType"
        android:propertyName="alpha"
        android:duration="@android:integer/config_mediumAnimTime" />
</set>

fragment_slide_right_exit.xml

<?xml version="1.0" encoding="utf-8"?>
<set xmlns:android="http://schemas.android.com/apk/res/android">
    <objectAnimator
        android:interpolator="@android:interpolator/decelerate_quint"
        android:valueFrom="0dp" android:valueTo="100dp"
        android:valueType="floatType"
        android:propertyName="translationX"
        android:duration="@android:integer/config_mediumAnimTime" />
    <objectAnimator
        android:interpolator="@android:interpolator/decelerate_quint"
        android:valueFrom="1.0" android:valueTo="0.0"
        android:valueType="floatType"
        android:propertyName="alpha"
        android:duration="@android:integer/config_mediumAnimTime" />
</set>

Now the activity that do all the transactions in the Fragment.

FragmentCustomAnimations.java

package com.example.fragmentcustomanimations;

import android.app.Activity;
import android.app.Fragment;
import android.app.FragmentTransaction;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.View;
import android.view.View.OnClickListener;
import android.view.ViewGroup;
import android.widget.Button;
import android.widget.TextView;

/**
 * Demonstrates the use of custom animations in a FragmentTransaction when
 * pushing and popping a stack.
 */
public class FragmentCustomAnimations extends Activity {
    int mStackLevel = 1;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.fragment_stack);

        // Watch for button clicks.
        Button button = (Button)findViewById(R.id.new_fragment);
        button.setOnClickListener(new OnClickListener() {
            public void onClick(View v) {
                addFragmentToStack();
            }
        });

        if (savedInstanceState == null) {
            // Do first time initialization -- add initial fragment.
            Fragment newFragment = CountingFragment.newInstance(mStackLevel);
            FragmentTransaction ft = getFragmentManager().beginTransaction();
            ft.add(R.id.simple_fragment, newFragment).commit();
        } else {
            mStackLevel = savedInstanceState.getInt("level");
        }
    }

    @Override
    public void onSaveInstanceState(Bundle outState) {
        super.onSaveInstanceState(outState);
        outState.putInt("level", mStackLevel);
    }


    void addFragmentToStack() {
        mStackLevel++;

        // Instantiate a new fragment.
        Fragment newFragment = CountingFragment.newInstance(mStackLevel);

        // Add the fragment to the activity, pushing this transaction
        // on to the back stack.
        FragmentTransaction ft = getFragmentManager().beginTransaction();
        ft.setCustomAnimations(R.animator.fragment_slide_left_enter,
                R.animator.fragment_slide_left_exit,
                R.animator.fragment_slide_right_enter,
                R.animator.fragment_slide_right_exit);
        ft.replace(R.id.simple_fragment, newFragment);
        ft.addToBackStack(null);
        ft.commit();
    }

    public static class CountingFragment extends Fragment {
        int mNum;
        /**
         * Create a new instance of CountingFragment, providing "num"
         * as an argument.
         */
        static CountingFragment newInstance(int num) {
            CountingFragment f = new CountingFragment();

            // Supply num input as an argument.
            Bundle args = new Bundle();
            args.putInt("num", num);
            f.setArguments(args);

            return f;
        }

        /**
         * When creating, retrieve this instance's number from its arguments.
         */
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            mNum = getArguments() != null ? getArguments().getInt("num") : 1;
        }

        /**
         * The Fragment's UI is just a simple text view showing its
         * instance number.
         */
        @Override
        public View onCreateView(LayoutInflater inflater, ViewGroup container,
                Bundle savedInstanceState) {
            View v = inflater.inflate(R.layout.hello_world, container, false);
            View tv = v.findViewById(R.id.text);
            ((TextView)tv).setText("Fragment #" + mNum);
            tv.setBackgroundDrawable(getResources().getDrawable(android.R.drawable.gallery_thumb));  
            return v;
        }
    }

}

You can download the complete source code from here.

Google And Blog: Is Your Cell Phone Private When Others are Involved?

Joe Pawlikowski — 2013-06-11T12:30:58+00:00

The government can access your phone records. We all pretty much knew that all along, but last week’s revelation of the NSA’s PRISM program confirmed everything we knew, and some that we didn’t. The conversation about privacy has taken center stage on a national level. Yet despite the outrage, a recent poll from Pew Research Center suggests that most Americans are okay with the government seeking call records — though “to investigate terrorism” seems like a key clause.

Another issue of cell phone privacy arose yesterday, but not on a national level. In the State of New Jersey, where I happen to reside, a local legislator has proposed a bill that would grant police officers the ability to search cell phone records in the case of car accidents. Operating a cell phone without a hands-free unit is illegal in New Jersey, and the bill’s sponsor says that granting officers this ability to search will make it easier for them to do their jobs.

In a way this makes sense. People text messaging while driving pose a hazard. The level of that hazard is up for debate, but it is a hazard in any case. Unfortunately, it is difficult to determine, for the sake of the accident repot and ensuing investigation, whether a driver was distracted by a cell phone. The bill would allow officers to find out on the spot.

Before we even get to the privacy issue, there is certainly one of effectiveness. If there is a passenger in the car, there’s essentially no way to prove wrongdoing on the part of the driver. Both parties can agree that it was the passenger who was operating the phone, and there’s little anyone can do to disprove that. Similarly, even if the driver were talking without a hands-free device, as long as he or she had such a device it would become a mitigating factor.

In terms of privacy, it’s understandable why people would be uncomfortable handing over their phones. If the officer doesn’t understand the smartphone operating system it can take many clicks to find the relevant information. In the process they can discover information they have no right seeing, and can then use that information against the phone’s owner. And how many abuse of power cases do we see from cops? Too many to make people comfortable with this kind of bill, I think.

Perhaps if I could watch over the office while he or she looked for the relevant information, I’d be more amenable to the bill. Then again, police don’t like it when citizens monitor them. More than likely this would turn into another unchecked privilege for law enforcement, which they would use to further solidify their power base. The more unchecked power we give law enforcement, the more they’re going to abuse that power at our expense.

The gist of the article is that this bill will likely make it all the way to the state, and perhaps federal, Supreme Court. As it should. This is the kind of issue we need to debate out in the open.

Via NJ.com.

The post Is Your Cell Phone Private When Others are Involved? appeared first on MobileMoo.

Android UI Patterns: Google's first pull-to-refresh - a good first try

Juhani Lehtimäki — 2013-06-10T22:03:10+00:00

In the lastest gmail update Google added a new way to manually force a refresh. This new way isn't really completely new. It greatly reminds the Twitter's pull-to-refresh while it differs visually.

Check out this video Abhilash Kuduvalli uploaded to Vine to see how the gmail app works: https://vine.co/v/b3PUHJeQpFd.

Pulling down the email list initiates an update. The update indicator itself replaces the action bar and disappears once the update is complete.

Should you change your refresh button to this?

No! This design pattern is something that has not yet found its form on Android. In fact, this is the very first time Google has done anything reminding the Twitter's pull-to-refresh in any of their apps. Expect this pattern to change before it endups in the official design guidelines.

However, if you're looking for something pull-to-refreshish and are not happy with Twitter's pull-to-refresh Chris Banes has created a library for implementing something similar to the gmail's approach.

ActionBar-PullToRefresh on github

Twitter's pull-to-refresh vs. Google's pull-to-refresh

Pull-to-refresh is a pattern that has received mixed response on Android. I've been a fan of pull-to-refresh and like the pattern enough to use it in my app. I'm not 100% sold on the gmail style though. My issue with it is that the interaction doesn't feel right. On touch screen we like to pull and swipe things. These gestures are pleasant as they react to our touch as we expect. That is also one of the strong points of twitter's pull-to-refresh approach. You pull the content down and it follows your finger. Google's implementation does not follow the finger and the interaction is indirect. You pull down but the refresh indicator appears horizontally and doesn't really have any connection to your touch.

To me, the feel of disconnected interaction is enough to not to recommend the gmail style pull-to-refresh yet. I believe that Google will keep refining this pattern as well as take in community feedback and ideas before they make this pattern a part of the platform. This development is promising, however. I think this is a step to the right direction and we'll soon have something that works very well.

Until then I'd recommend you to stick with the older approach or better yet, try to think how you don't need a manual update at all and keep your app's data fresh automatically.

Mark Murphy: The Busy Coder's Guide to Android Development Version 4.9 Released

Mark Murphy — 2013-06-10T12:57:43+00:00

Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 4.9, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!

First off, I have removed the C2DM chapter, as anyone using C2DM has hopefully migrated to GCM instead. Subscribers still using C2DM should hold onto a copy of an earlier edition in addition to downloading newer ones!

Beyond that, there are a fair number of improvements:

The chapter on sensors, retired long ago, has been rewritten and restored
There is a new chapter on using uiautomator for UI testing
The book also has a new chapter on using the fused location provider, from the Play Services enhancements announced at Google I|O 2013
The advanced ViewPager chapter was extended with a walkthrough of the usage and implementation of ArrayPagerAdapter, a more flexible fragment-based PagerAdapter implementation
The large-screen support chapter has a new version of the “EU4You” sample that uses SlidingPaneLayout (also introduced at Google I|O 2013), and the sensor sample app also demonstrates SlidingPaneLayout
The explanation of how resources are selected by the system was substantially overhauled
The coverage of Maps V2 was updated to reflect recent changes, such as being able to detect OpenGL ES 2.0 support at runtime (to fail over to another mapping option on older devices) and the deprecation of some location-tracking options
The book also sports various miscellaneous improvements and errata fixes, per usual

Also, users of the book in APK format who were encountering problems using the action bar home affordance to return to the table of contents should no longer run into that issue.

The next update (5.0!) is tentatively scheduled for mid-July.

EuroDroid: BBC Weather app hits Android

Gary_C — 2013-06-10T06:50:57+00:00

The BBC has launched a new Android app today, bringing us its classic weather forecast icon set along with a full mobile weather outlook. The app is simpler than many other rammed weather apps, offering a stylish prediction for the moment, which can be scrolled sideways for an hourly idea of future conditions. It also predicts wind speed, covers five days and lets you edit widget refresh frequency.

The app’s Home screen widget is particularly pretty, and we have already dedicated a permanent slot to it. The app also includes DashClock integration from the off, NFC location sharing and Daydream display for your docking pleasure. Here it all is:

It’s going to rain on Wednesday, but that’s OK as I’m already getting bored of watering the runner beans. The BBC Weather app is on Google Play here.

Chet Haase: DevBytes: Custom Activity Animations

Chet Haase — 2013-06-07T16:28:00+00:00

It's Friday: time for another DevBytes.

It's been a while, but they're back. At least until the queue runs out again and I write another glut of demos to talk about.

This episode, and most of the upcoming ones (teaser alert!) are around demos/code that we showed in A Moving Experience, the animation talk that +Romain Guy and I gave at Google I/O 2013.

Custom Activity Animations:
Window animations provide an easy way to animate transitions between activities. The animations can be customized to some extent, but there's only so much interaction between the launching and launched activities that you can take advantage of with the standard window animations.
This episode covers a different technique for fully customizable animations.

Video: http://www.youtube.com/watch?v=CPxkoe2MraA

Code: http://developer.android.com/shareables/devbytes/ActivityAnimations.zip

Google And Blog: Android Stock Keyboard Now Available in Google Play

Joe Pawlikowski — 2013-06-07T12:30:58+00:00

It might not sound like a big deal, but for Android users who find themselves frustrated with the available keyboard options it’s a boon. When I first got the Nexus One three-plus years ago, I absolutely loved the stock keyboard. I tried out SwiftKey and some alternatives, but stock ruled the day. The stock keyboard has gotten even better since then. That’s bittersweet news to Galaxy S3 users, because the Samsung keyboard is, well, not that great.

Earlier this year I raved about how SwiftKey is the best Android keyboard. What I meant was it was the best Android keyboard available for everyone (and for people who don’t like Swype, because people who like Swype love Swype). At the time the stock keyboard was left to those who had Nexus units or rooted their phones and used the stock version available through ROMs like CyanogenMod.

Yesterday Google mercifully released the stock keyboard in the Google Play Store, allowing anyone to download it in all its glory. Truth told, it’s not all that much better than Swiftkey, and it might not be any better at all. It will depend largely on user feel. But after typing away a few messages, I have a few notes.

On SwiftKey I routinely misfire when trying to type A, hitting the caps lock button instead. That is not an issue with the stock Android keyboard.
Almost everyone misfires occasionally when going for the space bar, hitting B or N instead. A good autocorrect, as you’ll find on Swype, will find two words with a B or N in between and insert the space there. So far the Android default keyboard has not done that yet.
Two settings I suggest changing: flip autocorrect to “aggressive” if you type very quickly (yet even this did not fix the space bar misfire issue) and uncheck the filter for obscene words. I’m sure you use them, and am equally sure you hate getting the f-word (hey, this is a family site) autocorrected to duck for no good reason.

You can get the Android stock keyboard at Google Play.

The post Android Stock Keyboard Now Available in Google Play appeared first on MobileMoo.

SlideME: Streamline Your Application Distribution with SlideME’s AppDF Support

SlideME — 2013-06-07T11:15:07+00:00

SlideME has teamed up with the One Platform Foundation to help developers distribute their applications across multiple stores. With the App Description File (AppDF) format, you can create a single file that describes your app and can be uploaded to multiple app stores. Within the AppDF file, you can combine your application’s market description, screenshots, the APK, promo graphics, icons, and video files.This will not only save you time, but helps in part to reduce the fragmentation of the Android ecosystem.

Hello Android: Insights from Google I/O 2013: How to Make Money from Android App Development

Guest — 2013-06-06T07:12:18+00:00

In comparison to iOS app, Android apps makes less money. Google may impress with its marketshare, but Apple is the leader when it comes to making money from apps. Google has been trying hard since a year and a half to create tools and systems to simplify the development and monetizing of Android apps. The Google Play Developer Console, launched in 2012, made the task of creating and publishing apps a little easier. But it was not enough.

Android Developers: Google Play Developer 8-Step Checkup

Android Developers — 2013-06-06T21:21:00+00:00

Posted by Ellie Powers, Google Play team

Google Play gives you tons of options on publishing your apps and connecting with users. But as you get started with new features like beta testing and staged rollouts, it’s a good idea to do a checkup and make sure you’ve covered the basics.

1. Boost your developer account security

If you take just one step today to protect your Google Play apps, enable two-step authentication for your Google account, and encourage the rest of your team to do the same.
Next, many developers first set up their Google Play account with their personal gmail account, but it’s actually a good idea to transfer your apps to a separate account. All of your installations and reviews remain intact. If you haven’t done this already, transfer your apps to a new account today.
Don’t share passwords. Instead, add each individual who needs access and only grant the minimum level of access they need — and encourage them to enable two-step authentication.
Review the list of people with access regularly, and when people leave your project, make it a standard practice to remove their access. Learn more about developer account security.

2. Protect your keystore

In order to publish an update to an existing app, you’ll need to sign it with the same keystore every time. If you lose your keystore, you’ll lose your history and reviews, so you’ll need to start over with new apps with new package name and a new key, so you’ll want to make sure you protect it. First, choose a secure password, and don’t use the same password that you use for your Google account. Next, back up your keystore somewhere, but don’t upload it to Google Drive with an account you use to publish on Google Play.

3. Check your email addresses

As a developer, you are responsible for checking two important email addresses:

Account owner email address: Google uses the address used to register your Developer Console to contact you about your apps and account, so it is extremely important that someone is responsible for checking it regularly. If necessary, you can forward messages from this account via Gmail, or transfer your apps to another account.
Customer support email address: For each individual application, you can specify the best way for users to contact you for customer support. Ensure that a valid support email address for your product is specified. As a best practice, this should probably be a designated support account that is checked regularly and not the same email as the address used to login to the Developer Console.

4. Familiarize yourself with the policies

We recently launched some new guides and examples for Google Play’s Developer Program Policies and Developer Distribution Agreement. Note that once you publish an app as free, you can’t change it to a paid app later, though you can add in-app products.

5. Set up team processes

You may have many people involved with your Google Play apps. Make sure roles are clear in terms of whose job it is to publish updates, check statistics and optimization tips, read and reply to user reviews, and track revenue. Make sure all of these people have the right access to the Developer Console. Many developers who are part of larger organizations also report to their larger teams about their apps’ performance. Designate someone to make sure your app description, graphics (including localized and tablet screenshots), and pricing are up to date.

6. Configure your Developer Console UI languages

To change the language you want to see the Developer Console in, set your primary language. If you speak additional languages, configure those, too — user reviews in those languages won’t be translated automatically in the Developer Console. That was a popular request from developers.

7. Refresh your app’s marketing materials

Optimize your Google Play image assets. Include a well designed feature graphic in your Google Play listing. Localize your feature graphic, screenshots and description to improve conversions globally. Create a great looking icon with the Launcher Icon Generator.
Provide screenshots specifically for phones and tablets showing both portrait and landscape layouts.
Improve your app’s marketing. Users are 47% more likely to trust & download content when you use the official Google Play Badge. Also, make sure you are linking to your apps properly. Use the Device Art Generator to create beautiful marketing material.

8. Stay on top of developer news

To make sure you’re aware of the latest Google Play updates for developers, make sure you check the Android Developers blog regularly, follow +Android Developers, and check the Developer Console regularly for announcements.

Join the discussion on

+Android Developers

Hello Android: Google Play downloads look to overtake Apple by this fall

morta — 2013-06-05T07:48:30+00:00

We talk a lot of smack about Apple around here, and this time I’m going to try and be a little kinder. Let me begin by saying congrats to Apple as they recently celebrated their 50-billionth app download. Ok, the ability to be nice stops there as it has been announced that Android users are currently downloading 500-million more apps per month than Apple, and at that rate Andy will speed on by and be the most popular on the market by this fall.

Android Developers: Bootstrap Your App's Cloud Services with Mobile Backend Starter

Android Developers — 2013-06-03T17:14:00+00:00

Posted by Brad Abrams, Product Manager, Google Cloud Platform

Many of the best mobile app experiences are powered by services in the cloud. Top Android developers such as Pulse and SongPop have long taken advantage of the convenience and scalability of Google's cloud platform in their businesses. Now with the Mobile Backend Starter, it's even easier to add cloud services to your apps.

Mobile Backend Starter

Mobile Backend Starter is a one-click deployable, complete mobile backend that allows you to reap the benefits of a cloud backend with none of the headaches. It provides a ready-to-deploy, general purpose cloud backend and a general purpose client-side framework for Android.

Mobile Backend Starter gives you everything you need to rapidly set up a backend for your app, without needing to write any backend code. It includes a server that stores your data with App Engine and a client library and sample app for Android that make it easy to access that data. You can also add support for Google Cloud Messaging (GCM) and continuous queries that notify your app of events you are interested in. To keep user data secure, Mobile Backend Starter also includes built-in support for Google Authentication.

Features of Mobile Backend Starter include:

Cloud data storage: Users change devices and increasingly use multiple devices. Store any amount of data per user in the cloud to be accessed from anywhere.
Pub/Sub messaging: Send messages from one device, to any or all other devices. You can easily use 1:1 and 1:many messaging as well as broadcasting. This feature is useful for various applications including social apps, forums, chat, gaming, and group collaborations.
Push notifications: Data updated on one device is automatically available on all devices with GCM for Android.
Continuous queries: Create queries that run continuously on the server, automatically feeding updates to the client. These queries are powered by Prospective Search.
Google authentication and authorization: Keep data isolated per user or shared among users.
Free to get started, scales with your needs: You can start by handling hundreds of users for free, then grow to any scale.

Quick setup and integration

You can set up and run the Mobile Backend Starter in just few steps:

First, go to the Google Cloud Console, and create a project. Then click Deploy.
Click on Settings to go to the admin control panel for your new backend. Under Authentication / Authorization, select "Open (for development use only)" and save the changes.
Next, download the Android client project and open it up in your Android IDE. Locate the Consts.java file and set the PROJECT_ID to the Project ID of the project you created in the Google Cloud Console.
Now just build and run the Android application and you have a cloud enabled Android application.

Check out the complete docs for details on setup as well as information on how to enable authentication, send push notifications, and use standing queries.

The best part is you can download the complete source code of the backend on GitHub and customize it however you want to meet your needs.

See Mobile Backend Starter in action at Google I/O

To see Mobile Backend Starter in action, check out our talk at Google I/O 2013 (embedded below) called "From Nothing to Nirvana in Minutes: Cloud Backend for Your Android Application". The talk shows how to use Mobile Backend Starter to create a new backend server and integrate it with an Android app via Google Cloud Endpoints and the Google Plugin for Eclipse.

We look forward to hearing your questions and learning about the amazing applications you have built. You can find us lurking on the Cloud Endpoints StackOverflow forum.

Join the discussion on

+Android Developers

Luke Meyer: Android and openness

Luke Meyer — 2011-06-12T00:59:54+00:00

On Thursday I gave a talk at TriLUG. The slides I used are available but will probably be rather cryptic without my accompanying commentary.

Although I understand that Google has had to contend with both the open source zealots and the closed-everything carriers, upon looking at the trend, I find Google’s actions getting more disturbing. Just as Android seems to be coming into its own and Google should have more power than ever to twist arms, Google seems to be wimping out – or turning evil. I hope I’m wrong and they’re just waiting for the right time.

One thing I completely forgot to talk about is the abandoning of the Nexus One. When it came out, it was supposed to herald a new age of cross-carrier, stock-Android phones (with a built-in connection-sharing capability, no less). Only T-Mobile really picked it up – you could use it on AT&T but without 3G. Verizon and Sprint were supposed to be coming out with support for the same concept and just a different radio, but instead they released their own phones, with the usual modifications and constraints. So why did Google let them? They didn’t have to; the Skyhook case shows that Google can essentially pull their blessing from any phone for any reason. An Android phone without the Google apps isn’t going to be very attractive to consumers. Why didn’t Google force Verizon and Sprint to kowtow to the Nexus One before allowing them to release any more Android phones?

Luke Meyer: Is this thing on? ::feedback:: ouch…

Luke Meyer — 2011-04-01T01:01:13+00:00

Well – I don’t want to let the *entire* month of March go by without a post. I just haven’t done much with tech this month, though. It sucked. But evidently my absence has caused a surge in popularity, according to my stats. Less is more?

If I remember correctly – is Honeycomb the first version of Android where we actually saw a preview, got to fiddle with the SDK platform preview before it was actually embodied in a device? If so, better late than never, and let’s hope it means we’re on the way to seeing more of a community effort. Hey, it took a while for Red Hat to learn with Fedora, too, and they didn’t have voracious proprietary partners to contend with.

I have a meetup or two to arrange, but I hope I get some time to work further with ORMlite shortly.

Happy April Fools Day tomorrow!

Marakana: Android Enterprise Security at AnDevCon

Marko Gargenta — 2013-05-29T14:36:00+00:00

Android provides the plumbing to make it an enterprise-grade mobile platform of choice. This is a talk given at AnDevCon in Boston.

Marakana: Android Security Underpinnings at AnDevCon

Marko Gargenta — 2013-05-29T14:31:00+00:00

Android Security Underpinnings explores how the Android security system is put together. This is a talk given at AnDevCon in Boston.

Romain Guy: Android sessions at Google I/O 2013

Romain Guy — 2013-05-17T20:14:55+00:00

Google I/O 2013 is almost over but a lot of sessions are already available online. I gave three talks this year and you can watch them today on YouTube:

Writing Custom Views for Android, with Adam Powell
A Moving Experience, with Chet Haase
Android Graphics Performance, with Chet Haase

In addition you can download the slide for the Android Graphics Performance talk:

Keynote (7MB)
PDF (13MB)
PDF with notes (13MB)

And the slides for A Moving Experience:

Keynote (7MB)
PDF (13MB)
PDF with notes (13MB)

If you have a copy of Keynote I recommend you choose this format to get both the notes and all the animations on the slides. Enjoy!

Romain Guy: Launcher

Romain Guy — 2013-01-02T17:24:33+00:00

I recently discovered MyColorScreen where Android users publish their beautiful home screen setups. I am impressed by the work and care that people put in customizing their home screen and I am also proud to see this because it’s exactly what we intended when we decided users could replace the default Launcher with their own.

Since some of you asked to see my own setup, here it is. It’s basic and boring but very efficient for me.

EuroDroid: STATS: Android powers 58.4% of UK smartphone sales in 2013

Gary_C — 2013-04-29T11:11:55+00:00

Analyst Kantar Worldpanel has issued some updated analysis of the UK and European smartphone scene, revealing that Android powered a whopping 58.4% of all smartphones sold in the UK during the three-month period to the end of March 2013. As in, the three months before the Galaxy S4 and HTC One launched. It’s going higher.

iOS is down as a result, dropping by 1.4% to take 28.9% of smartphone sales, while Windows Phone actually saw some GOOD NEWS for once – Microsoft’s mobile market share is up to 7% from the 2.9% it had in the same quarter of 2012. Smartphones accounted for 84% of all phone sales during the three-month period.

Bizarrely, Android’s absolutely SMASHING IT in Spain, where it holds an amazing 93.5% of the smartphone market according to Kantar’s stats. Good on you, Spain. Read more over at Kantar.

Cyril Mottier: Pushing the ActionBar to the next level

2013-05-24T12:29:00+00:00

Back in November 2012, I wrote a blog post entitled ”ActionBar on the Move”. This article was mainly dealing with a technique to nicely and uniquely animate your ActionBar. Although I mentioned some of the effect’s possible applications, I never had time to effectively add an ActionBar animation to one of my own apps nor saw an application on the Play Store taking advantage of it.

While being at Google I/O last week, I finally found an application using the ActionBar animation technique. Let’s be honest, it literally blew my mind the first time I saw it. I felt in love with the nice, subtle and yet extremely useful animated effect probably more than the entire app itself! I am pretty sure you know the application I am talking about as it has been presented during the Google I/O keynote. You have also probably recently received an update of it: Play Music!

The latest update of Play Music (v5.0) has been completely redesign and features a brand new artist/album detail screen. If you open such a detail screen, you’ll notice the ActionBar is initially invisible and overlaps a large image describing the artist/album. Once you start scrolling down (if possible), the ActionBar fades in gradually. The ActionBar turns completely opaque when the large image has been scrolled out of the screen.

Here are two main advantages of this ActionBar animation:

Polish the UI: animations synchronized on an element you’re interacting with are generally appreciated by users because it makes them feel the UI is natural and reacts to their actions. The fading animation is a direct consequence of the per-pixel scrolling state and not a launched-once animation.
Take advantage of the screen real estate: while still preserving the UX of the platform, this pattern let the user primarily focus on the content rather than the controls. Used in addition to a nicely designed screen, it can be a game changer for your app’s interface.

In this article, I will deep dive into the details of implementing the technique described in ”ActionBar on the Move” to create an effect similar to the one used in the Play Music app.

In order to better understand the goal we are targeting, you can have a look at the screenshots below or alternatively download the sample application.

Application theming/styling

As you can easily notice, in order to reproduce such an effect, the ActionBar must overlap the content of the screen. This can be easily done using the android:windowActionBarOverlay XML attributes. The code below describes the definition of the themes we’ll use:

values/themes.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <style name="Theme.TranslucentActionBar" parent="@android:style/Theme.Holo.Light.DarkActionBar">
        <item name="android:actionBarStyle">@style/Widget.ActionBar</item>
    </style>

    <style name="Theme.TranslucentActionBar.ActionBar" />

    <style name="Theme.TranslucentActionBar.ActionBar.Overlay">
        <item name="android:actionBarStyle">@style/Widget.ActionBar.Transparent</item>
        <item name="android:windowActionBarOverlay">true</item>
    </style>
</resources>

Pretty logically, the style of the ActionBar is defined in values/styles.xml as follows:

values/styles.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <style name="Widget.ActionBar" parent="@android:style/Widget.Holo.Light.ActionBar.Solid.Inverse">
        <item name="android:background">@drawable/ab_background</item>
    </style>

    <style name="Widget.ActionBar.Transparent">
        <item name="android:background">@android:color/transparent</item>
    </style>
</resources>

Finally, we can use these themes in order to style our Activity.

AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.cyrilmottier.android.translucentactionbar"
    android:versionCode="1"
    android:versionName="1.0" >

    <uses-sdk
        android:minSdkVersion="14"
        android:targetSdkVersion="17" />

    <application
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/Theme.TranslucentActionBar">

        <activity
                android:name=".HomeActivity"
                android:theme="@style/Theme.TranslucentActionBar.ActionBar.Overlay">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

    </application>

</manifest>

Note that by using themes/styles we remove all potential flickering issues at startup (see Android App Launching Made Gorgeous for more information).

Getting the content ready

As explained previously, the ActionBar fading is synchronized on the per-pixel state scrolling of the scrolling container. In this example, we’ll simply use a ScrollView as a scrolling container. One of the major drawback of this container is you can’t register a listener in order to be notified when the scroll has changed. This can be easily done be creating a NotifyingScrollView extending the original ScrollView:

NotifyingScrollView.java

package com.cyrilmottier.android.translucentactionbar;

import android.content.Context;
import android.util.AttributeSet;
import android.widget.ScrollView;

/**
 * @author Cyril Mottier
 */
public class NotifyingScrollView extends ScrollView {

    /**
     * @author Cyril Mottier
     */
    public interface OnScrollChangedListener {
        void onScrollChanged(ScrollView who, int l, int t, int oldl, int oldt);
    }

    private OnScrollChangedListener mOnScrollChangedListener;

    public NotifyingScrollView(Context context) {
        super(context);
    }

    public NotifyingScrollView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public NotifyingScrollView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }

    @Override
    protected void onScrollChanged(int l, int t, int oldl, int oldt) {
        super.onScrollChanged(l, t, oldl, oldt);
        if (mOnScrollChangedListener != null) {
            mOnScrollChangedListener.onScrollChanged(this, l, t, oldl, oldt);
        }
    }

    public void setOnScrollChangedListener(OnScrollChangedListener listener) {
        mOnScrollChangedListener = listener;
    }

}

Then, we can use this new scrolling container in an XML layout:

layout/activity_home.xml

<?xml version="1.0" encoding="utf-8"?>
<com.cyrilmottier.android.translucentactionbar.NotifyingScrollView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/scroll_view"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="vertical">

        <ImageView
            android:id="@+id/image_header"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:scaleType="centerCrop"
            android:src="@drawable/daft_punk"/>

      <! -- Some long content -->

    </LinearLayout>

</com.cyrilmottier.android.translucentactionbar.NotifyingScrollView>

Fading in/out the ActionBar

Now most of the boilerplate is ready, we can plug all of these components together. The ActionBar algorithm is rather simple and only consists on computing the alpha depending on the current per-pixel scrolling state of the NotifyingScrollView. Note that the effective scrolled distance must be clamped to [0, image_height - actionbar_height] in order to avoid weird values that may occur mainly because of the default over scroll behavior of scrolling containers on Android:

HomeActivity.java

package com.cyrilmottier.android.translucentactionbar;

import android.app.Activity;
import android.graphics.drawable.Drawable;
import android.os.Build;
import android.os.Bundle;
import android.support.v4.view.GravityCompat;
import android.support.v4.widget.DrawerLayout;
import android.util.Log;
import android.view.Menu;
import android.widget.ScrollView;

public class HomeActivity extends Activity {

    private Drawable mActionBarBackgroundDrawable;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_home);

        mActionBarBackgroundDrawable = getResources().getDrawable(R.drawable.ab_background);
        mActionBarBackgroundDrawable.setAlpha(0);

        getActionBar().setBackgroundDrawable(mActionBarBackgroundDrawable);

        ((NotifyingScrollView) findViewById(R.id.scroll_view)).setOnScrollChangedListener(mOnScrollChangedListener);
    }

    private NotifyingScrollView.OnScrollChangedListener mOnScrollChangedListener = new NotifyingScrollView.OnScrollChangedListener() {
        public void onScrollChanged(ScrollView who, int l, int t, int oldl, int oldt) {
            final int headerHeight = findViewById(R.id.image_header).getHeight() - getActionBar().getHeight();
            final float ratio = (float) Math.min(Math.max(t, 0), headerHeight) / headerHeight;
            final int newAlpha = (int) (ratio * 255);
            mActionBarBackgroundDrawable.setAlpha(newAlpha);
        }
    };
}

As described in ”ActionBar on the Move”, this snippet of code above doesn’t work for pre-JELLY_BEAN_MR1 devices. Indeed, the ActionBar isn’t invalidating itself when required because it isn’t registering itself as the Drawable’s callback. You can workaround this issue simply be attaching the following Callback in the onCreate(Bundle) method:

HomeActivity.java

private Drawable.Callback mDrawableCallback = new Drawable.Callback() {
    @Override
    public void invalidateDrawable(Drawable who) {
        getActionBar().setBackgroundDrawable(who);
    }

    @Override
    public void scheduleDrawable(Drawable who, Runnable what, long when) {
    }

    @Override
    public void unscheduleDrawable(Drawable who, Runnable what) {
    }
};

HomeActivity.java

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
    mActionBarBackgroundDrawable.setCallback(mDrawableCallback);
}

You can already run the code “as it”. Although the result looks alike the animation used in Play Music we can still continue to tweak it to make it better.

A final brush stroke

Enforcing ActionBar contrast

Having an transparent ActionBar may lead to design issues because you generally don’t know about the background you’ll be displayed on top of. For instance you may end up with a transparent ActionBar displaying a white text on top of a white description image. No need to say it makes the ActionBar invisible and useless.

The easiest way to avoid such a problem consists on modifying the image to make it a little bit darker at the top. Thus, in a worse case scenario (i.e. white image) we would have a grey area on top of the image making the ActionBar content (title, icons, buttons, etc.) visible.

A simple way to do that is to overlay a translucent dark to transparent gradient on top of the image. This can be done in XML only with the Drawable described below:

drawable/gradient.xml

<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android"
       android:shape="rectangle">

    <size android:height="100dp"/>

    <gradient
        android:angle="270"
        android:startColor="#8000"
        android:endColor="#0000"/>

</shape>

The gradient is overlaid using a wrapping FrameLayout:

layout/activity_home.xml

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <ImageView
        android:id="@+id/image_header"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:scaleType="centerCrop"
        android:src="@drawable/daft_punk"/>

    <View
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:background="@drawable/gradient"/>

</FrameLayout>

Avoid over-scroll

In Gingerbread (API 9), Android introduced a brand new way to notify the user a scrollable container is being scrolled beyond the content bounds. First it introduced the notion of EdgeEffect (available in the API starting API 14) and enabled over-scroll. While this is not a problem in general, it can be pretty annoying when one of the edge of your scrollable content is different from the background color.

You can reproduce it be simply flinging the ScrollView rapidly to the top and you’ll notice some white color (the background color) appears on top of the screen because the image is scrolling beyond the bounds. I personally consider this a a UI glitch and usually prefer disabling it in this rare cases.

One could imagine the best way to avoid over-scroll is to use View#setOverScrollMode(int) to change the mode to View#OVER_SCROLL_NEVER. Although it works, it also remove the edge effect which can be visually disturbing¹. A simple way to do that is to modify the NotifyingScrollView to force the maximum over scroll values to zero when necessary:

NotifyingScrollView.java

private boolean mIsOverScrollEnabled = true;

public void setOverScrollEnabled(boolean enabled) {
    mIsOverScrollEnabled = enabled;
}

public boolean isOverScrollEnabled() {
    return mIsOverScrollEnabled;
}

@Override
protected boolean overScrollBy(int deltaX, int deltaY, int scrollX, int scrollY, int scrollRangeX, int scrollRangeY,
                               int maxOverScrollX, int maxOverScrollY, boolean isTouchEvent) {
    return super.overScrollBy(
            deltaX,
            deltaY,
            scrollX,
            scrollY,
            scrollRangeX,
            scrollRangeY,
            mIsOverScrollEnabled ? maxOverScrollX : 0,
            mIsOverScrollEnabled ? maxOverScrollY : 0,
            isTouchEvent);
}

Conclusion

I seriously don’t know if the team behind the Play Music application decided to implement the behavior based on my article. But it appears they brilliantly used the technique to both polish and emphasize the UI. It is clearly an awesome pattern to use whenever you need to design a screen which content is self-explanatory and is more important than the ActionBar content itself.

Do not ask me why the naming of the constants/method is so ambiguous…

Cyril Mottier: Enhancing Google Maps API v2 with Polaris v2

2013-05-02T12:00:00+00:00

In October 2012, I released a library called Polaris. At that time, the library received quite a lot of success because it was really filling the mammoth blanks of the Google Maps external library (aka Google Maps Android API v1): effortless map annotation, gesture support, map callout support, built-in “user tracking” mode, etc. If you have never heard of Polaris feel free to checkout one of the links below:

(Un)fortunately - the addition/removal of the ‘un’ obviously depends on the point of view - Google released a radically different and new version of the library in December 2012. In addition to this release they announced the deprecation of the first version of the API as of March 2013¹. Let’s be honest, at first I was pretty annoyed by this new release because it turned almost all of my work to a waste of time. On the other hand, I was quite happy to notice the new API were really close - functionaly and API-ly speaking - to what I did on my own with Polaris.

Back in December I gave my point of view about the new Google Maps Android API v2. After almost 6 months, the library has been updated only once (as part of the Google Play Service, it was supposed to be updated very often…) and is not a great starting base for building libraries on top of it (all of the classes are final and hence cannot be extended).

With the release of AVélov 1.2, a lot of people were interested in the animated clustering algorithm I developed. Several companies asked me for the app source code and I was quite frustrated not being able to deliver a true library but only a sample code. That was true until I decided to find a way around the Google’s locked down library. I finally managed to by-pass the ‘final’ limitation fairly easily. I entirely wrapped the original Google’s library into my own library: Polaris v2.

Introducing Polaris v2

The main purpose of Polaris v2 is to act as the root component for creating library projects around the Google Maps Android API v2. Although I originally developed it for creating commercial library providing animated clustering, I extracted the essence of it and kept some basic features. As a consequence, Polaris v2 aims to fix some of the most frustrating bugs of the original library and provide additional features.

For now, the code is mostly a wrapper but I’m releasing and open-sourcing the code so that the community can contribute to it and enhance it with some awesome new features and fixes. The current release includes just a few improvements (see the README file on GitHub for more information). Hopefully, some of the changes introduced in Polaris v2 will be backported into Google Maps Android API v2…

Using Polaris v2 in your projects

Using Polaris v2 in your projects is quite simple. The API exposed by Polaris v2 is a super-set of what the original Google Maps Android API v2 exposes. As a result, you only need to switch all of the imports from the Google Maps Android API v2 (com.google.android.gms.maps.*) to Polaris v2 (com.cyrilmottier.polaris2.maps.*)

Finally you can start interacting with the underlying GoogleMap by calling getPolarisMap() (instead of getMap()) on your SupportMapFragment, MapFragment or MapView.

Conclusion

While the original project at the root of Polaris was more featureful, this release is the perfect way for developers to start adding some missing features to the original Google-provided mapping library. Today, Polaris v2 is just a wrapper around the Google Maps Android API v2 but could easily become a must-use library in the future. The project is just waiting for the community to help it grow.

Having a deprecated API doesn’t mean it is not working anymore for all existing applications. Google only decided to prevent people from generating new API keys. As a consequence, it is now impossible to create new applications using the Google Maps external library except if you are signing your application with a certificate you already have assigned a map API key to.

Chris Boyle: Android keymaps

Chris Boyle — 2010-08-22T14:32:41+00:00

I recently bought a Bluetooth keyboard to use on Android; unfortunately some keys weren't recognised at all and others weren't quite mapped as I'd like. This is fairly easy to fix as an end user, as long as you have a rooted device (adb remount must succeed). Here's a quick howto, since I couldn't find one.

It shouldn't need saying, but you do this at your own risk. You can easily break your device's response to keys, and possibly make your device unbootable too if the file is invalid.

It's pretty much as described under Keymaps and Keyboard Input in the porting documentation. What we're going to do is edit one file: /system/usr/keylayout/qwerty.kl. This file maps scancodes to Android keycodes. For example: key 30 A means scancode 30 (decimal) maps to KEYCODE_A (29), the A key. As the porting docs say, a separate Key Character Map file deals with what characters, if any (e.g. "a", "A", "#"), should be generated given the keycode and the state of the modifiers (Shift, Fn/Sym, etc). A different KCM can be loaded for Bluetooth keyboards depending on their device name, but at least by default, the same key layout file (including your changes) is used for Bluetooth and the built-in keyboard (if any).

So, first we need to fetch your current key layout, and it's a good idea to keep backups (both on the device and locally).

1 adb pull /system/usr/keylayout/qwerty.kl qwerty.kl
2 cp qwerty.kl qwerty-orig.kl
3 adb shell cp /system/usr/keylayout/qwerty.kl /sdcard/qwerty-orig.kl

Now, edit qwerty.kl as you like. It should look initially look similar to this Nexus One example. You might find it helpful at this point to see what scancodes your keyboard is sending. There really ought to be a tool for this in Dev Tools or Spare Parts, but it seems there isn't. I've made a dirt-simple app to show you KeyEvent.toString(), which was the work of 5 minutes and could certainly be improved.

My particular keyboard is a white roll-up 87-key variety, that you can still find on eBay. It has F-keys doubling as media keys: if you get this model, be aware that the Fn key is really F-lock (toggles the state rather than acting as a modifier). Here is my layout file in case it's helpful. This layout mostly follows the principle of least surprise, except that the button with "Home" printed on it is Call, to mirror "End" being Hangup. F1 with F-lock on (Home symbol) is the Android "Home" keycode (goes to the home screen).

Now copy the layout back onto the device:

1 adb remount
2 adb push qwerty.kl /system/usr/keylayout/qwerty.kl

(If the remount fails, you probably don't have a rooted device.) It seems you need to reboot for the changes to take effect, so go ahead and do that, and your keys should then behave as you've specified. :-)

Comments preferred at http://chris.boyle.name/2010/08/android-keymaps using OpenID/Facebook/Twitter (comments elsewhere are unlikely to reach me).

Chris Boyle: What next?

Chris Boyle — 2010-10-09T21:18:57+00:00

Now that my various projects seem to be mostly behaving themselves, it's time to decide what to write next. I've had a few requests and a few ideas, so here's a rundown of possibilities.

Locale condition: ping. Let Locale ask "is that machine awake?" It could ping something in a private IP range, deduce that you're at home and your PC is on, and stop notifying you about things you're already likely to see on the PC. There seems to be a usable ping command in Android's busybox, but for bonus points, allow a TCP ping, maybe check the banner on a service, to guard against collisions with private IPs in other places.
Locale action: K9 settings. It's been done.
Locale action: ConnectBot. You can already configure a ConnectBot session to immediately run a command. Launching a remote shell script securely from Locale would add some nice flexibility: aggressive notification using PCs around the house, X10 home automation, garage doors… you could do this from ASE with an ssh client binary, but that's a little harder to install, especially without root.
Locale condition: Timer. My timer, not yet formally released, could trigger the aforementioned aggressive notification if alarms have gone unanswered for half an hour. Update: Done.
Port this site to Rails 3. This can wait until v3 is actually out.
Puzzles improvements. Some ideas languishing in the bug tracker, including multiplayer.
Set up mpd (with neompc on an old Palm Treo) at home. Probably no new code needed, but included for completeness.

Most of these will probably happen eventually, but it's always useful to know which ideas are useful to a wider audience, so feel free to comment or contact me if you're keen to see one of these created, or if you can think of improvements or existing projects I ought to be aware of. I'll also be writing up any interesting aspects of these projects as I implement them, and suggestions for posts of that kind that you'd like to see are also welcome.

Comments preferred at http://chris.boyle.name/2010/07/what-next using OpenID/Facebook/Twitter (comments elsewhere are unlikely to reach me).

The Powerbase: PhoneSats in Orbit, Transmitting Data To Listeners Worldwide

Tom Nardi — 2013-06-06T23:57:35+00:00

After a few delays, the inaugural mission of the Orbital Sciences Antares mission successfully made it into orbit on April 21st. While the mission didn’t carry the actual spacecraft Antares is designed to lift (that’s currently slated for June), it didn’t go up there empty handed.

The Antares rocket safely delivered all three of NASA’s PhoneSats into their intended orbit, and according to amateur radio operators all over the world, the three micro-satellites are performing as expected.

NASA’s PhoneSat

Global Effort

As the PhoneSat satellites have rather limited transmission capability, NASA is relying on a global network of amateur (AKA ham) radio operators to keep an ear out for these tiny little craft.

By openly documenting the spacecraft’s packet protocols, listing the frequencies they will be transmitting on, and even displaying an animated map to show where each PhoneSat is in the sky, NASA has given the public everything they need to receive regular downlinks.

Once a radio operator has received one of these broadcasts, he or she can upload it to the PhoneSat.org site, where it will be cataloged. When enough data has been collected, NASA will (hopefully) be able to piece together information spanning the entire mission, including the sensor data and images the PhoneSats are constantly sending out.

Listen Up

Interested in trying your hand at receiving signals from these Android-powered spacecraft?

It’s not nearly as complex as you probably think, as there are now multiple low-cost USB radios which can be used to receive satellite transmissions. All you need is a decent antenna, and some patience.

Take a look at our guide on RTL-SDR for some ideas on how you can get started in the fascinating world of amateur radio for around $30 USD.

The Powerbase: Reimagining Play: Interview with PlayMG’s Taylor Cavanah

Tom Nardi — 2013-06-06T23:57:35+00:00

Last month, we brought you a review of the MG, an Android powered handheld gaming system designed for casual games. The combination of vanilla Android and the MG’s custom parental controls made the device a compelling option for gamers young and old alike, and its comparatively low price combined with the vast Android software library offered an unbeatable value.

The team behind the MG had obviously done their homework and targeted the product to a very specific market which was otherwise being ignored. Rather than throwing out a half-realized device that didn’t resonate with any particular use case, the team engineered the hardware and software experience to their target audience to great effect.

Taylor Cavanah

To learn more about the focus and vision which made the device a reality, we got in touch with MG’s physicist turned meta-gamer Taylor Cavanah.

Creating the MG

The Powerbase: Taylor, thanks for taking the time to talk with us. Can you start by telling our readers a bit about yourself and your background?

Taylor: I’m a physicist and started my career in Nanotechnology at Zyvex. After finding some success in developing the nanoprobing market for the semiconductor industry I decided to strike out on my own. My buddies and I started our own software company – Locai – and a year ago we combined forces with the hardware and business guys from ACTScom to launch PlayMG.

The Powerbase: What exactly is your role at PlayMG? What are your day to day responsibilities like?

Taylor: My specific role involves game/app design, platformsoftware design, business development, innovation, and as is the case with all start ups – many more roles. Day to day I was either talking with game houses, working with the hardware guys to design the user experience, writing the story behind our game within the gaming device app Origins, looking for interesting apps to work with, working with marketing to craft the messaging behind these features we were building, and testing devices in every possible way.

The Powerbase: PlayMG has no qualms about the fact it has targeted the MG to younger gamers. Why do you think the younger gamer is so important? What makes the MG a better option than, say, mom’s old smartphone?

Taylor: Every one has a slightly different opinion on this but for me the younger gamers make the most sense because they can’t have phones. Whether their parents don’t want them or can’t afford the data plans, there are a lor of younger gamers who love apps but can’t get access to them. The “hand me down” argument is definitely valid. I can hand down my phone and just remove the plan and then they have a smart device. That’s where our added benefits factor in to the equation. You can’t get Family Collaboration, SpendSmart, or the Origins game in a hand me down. And sometimes more importantly, you can’t get that “awe” moment when your son or daughter opens up your repackaged device from 2 years ago.

Android and the MG

The Powerbase: Its differences aside, the majority of the MG’s software is straight Android. Would it be safe to say that, if it wasn’t for the open nature of Android, the MG wouldn’t exist in its current form? Would have putting this same hardware out with a proprietary operating system have gotten you as far as Android has?

Taylor: There is no way we would exist without Android. The barrier of entry previously was just too high. We got a solid and awe inspiring product to market in 9 months. Core to that was not having to build an entire OS. Not just in terms of getting something to market but that greatly helped us focus our time and money where it mattered – on the added benefits like Family Collaboration and Origins. This is what I love about open source – you get to make products with extremely well designed experiences where it matters.

The Powerbase: One of the biggest selling points early on was that the MG would be a vanilla Android device, meaning it would be as close to AOSP as possible. In the end the MG delivered on that promise, and is one of the few non-Nexus devices available running stock Android. Why was running stock Android so important for the MG?

Taylor: Part of that answer has to do with my previous answer – it’s just easier to not build stuff you don’t need. I think everyone can point to some larger companies that have large engineering staffs that have to build stuff because those salaries are being spent no matter what. Then you get a lot of customization away from stock. But most of that is useless and provides no value to the customer experience. A lot of engineers also like the job security that building all of this custom stuff gives them. They will always be needed because only they know how this version of flavored Android operates. For us it was exactly that overhead that we didn’t want. If we build our own flavor of Android then every new app or platform we create down the road has to take that into account. We had to keep our focus on what mattered for the end user.

The Powerbase: From a development perspective, stock Android is generally preferable to manufacturer modified builds, but what about the end user? It’s no secret that the most popular Android devices (such as Samsung’s Galaxy line) make use of manufacturer modifications to their interface and applications, so the public doesn’t seem to mind. Do you ever worry that shipping with stock Android rather than a build with more visual flair and streamlined functionality pleases the developers at the expense of the end users?

Taylor: I have never believed that popularity of a device has anything to do with how well it is designed or received by customers. The large software guys have proven time and again that being big in a space and having a ton of money can make up for a lot of deficiencies. I say this because I don’t believe customers buy the Galaxy line because of the manufacturer improvements – most customers have never seen stock Android so they don’t know any better. My guess is the commercial bashing the iPhone (hilariously with the parents in line) did a lot more than the user experience. From what I’ve seen all of the added modifications make little difference to the real end users (not us tech types who are too deep in the space). We found you could do an amazing amount of things just using the widget system in Android to change the user experience – without huge teams to build and then manage modifications.

The Powerbase: Some would say that shipping the device with vanilla Android only makes sense if it’s kept up to date with AOSP (such as the Nexus line), but the MG is still on 4.0.4. Why hold the MG back? Are there plans on updating to Jelly Bean (and beyond)?

Taylor: We will update to Jelly Bean. But with such a low saturation of Jelly Bean and many apps still not upgraded for the experience it doesn’t make sense to expend the effort. Again we’ve got to focus on that end user experience and the only people ever asking for Jelly Bean are analysts or the random parent who just saw some article that mentioned the new Jelly Bean thingy for Android.

Expanding Android Gaming

The Powerbase: One of the best features of the MG, at least for parents, is unquestionably the Family Collaboration System. While it currently sets the MG apart from the competition, would PlayMG consider bringing it to generic Android devices? Perhaps charging a monthly subscription fee when used on non-MG hardware?

Taylor: We are always weighing the pros and cons of releasing some of the proprietary apps to the Play Store. Right now we only have to manage one device, we get to ignore fragmentation, and we have a competitive advantage. I don’t see us releasing the apps until we are much more established.

The Powerbase: An advantage of putting out an Android based gaming system is, of course, that you aren’t responsible for developing or publishing games for it (unlike traditional game consoles). That said, are there plans to talk to developers about MG optimized games? Is that already happening?

Taylor: Nothing that I can talk about but we definitely have plans and some preliminary talks about using our PlayMG IP to create games. Any game developers interested (especially if they want to do something outside of the normal bounds of gaming) should get in touch with us.

The Powerbase: You can’t talk about Android gaming anymore without mentioning the OUYA; while it’s aiming for a completely different market than the MG, are there any parallels you draw between them? Do you see families owning both devices in the future?

Taylor: Mine arrives in 3 weeks (if I had more time and money I would have gotten a developer version). I would love to work with OUYA in the future and I do believe that console gaming and portable gaming will always be with us. Where the hardware, software, and interfaces end up who knows but for now there are many opportunities that could be explored between the two companies. For the next year though I’m guessing both of us will be too busy to pursue them.

Looking Ahead

The Powerbase: A common criticism of the MG is that it lacks physical controls. This was a design decision based on the intended userbase for the MG, but it’s also undeniable that there are hardcore gamers out there that would appreciate an MG-like device with physical input. Is this a challenge PlayMG might take up in the future? Perhaps a device like the Sony Xperia Play, but in a non-contract form like the MG?

Taylor: I don’t see that happening. Our target user is not hardcore and in fact probably did not grow up with a game system that had controllers. But at an even deeper philosophical level (get ready for the fan boy to come out) I think the portable gaming systems with controls aren’t just missing the mark but don’t really have a mark to hit. Portable gaming is about the casual experience on the go or that little block of entertainment that you carry around in your pocket. I have so many different serious game devices where I can have mind blowingly immersive experiences – but that’s not what you want in a portable gaming device. At the end of the day we talked to a bunch of “gamers” in our demographic and they wanted a device they could put in their pocket versus a device that let them play games designed for pre-touch devices.

The Powerbase: If it’s not giving too much away, what can you say about the future of PlayMG and the MG itself? Anything current or future owners should be looking out for?

Taylor: We have some great plans for the Family Collaboration System – making it much more collaborative. A lot of parents and even kids have asked for expanded features here. I’m most excited about expanding the portable fun in the device. The entire industry as a whole is barely scratching the surface of what you can do with portable gaming. We have some very interesting things planned for making shared portable gaming experiences like no one has seen before. Unfortunately I can’t say much more than that.

Thanks to Taylor and the entire PlayMG team for their assistance and professionalism while we worked on the original hardware review and this interview. We’re very interested in seeing where the future takes PlayMG, keep an eye out here on The Powerbase for future coverage of this unique company and its products.

Gushiku Studios: Box2D video tutorials on collision filtering

gushikuadmin — 2013-04-06T22:21:41+00:00

Gushiku Studios has posted three Box2D tutorials to Youtube. They primarily deal with applying collision filtering for interesting effects for games and apps.

The first video is a tutorial detailing how collision filtering works via category and mask bits in Box2D. You can find that video here.

The next video demonstrates an approach to implementing one-sided platforms using sensor fixtures. You can find that video here.

Finally, the last video demonstrates how to implement a railway switch type construct, similar to what you might create for a pinball game. You can find that video here.

Gushiku Studios: RUBE + RubeLoader + libgdx + Box2d video = FTW

gushikuadmin — 2013-03-23T18:20:09+00:00

Gushiku Studios has posted a Youtube tutorial on using RUBE with the RubeLoader for the cross-platform development frameworks libgdx. What is RUBE? It stands for "Really Useful Box2D Editor" and the name definitely fits! You can check out more information about RUBE on iforce2d's website. The RubeLoader repo on Github provides a loader that will read in .JSON data generated by RUBE for Box2D worlds using libgdx. Included in the repo is a self-contained example demoing the capabilities of the loader along with a sample rendering approach.

See ALL of Gushiku Studios releases on Google Play, Slide Me and the Amazon App Store!

DroidDevelop Stream: P145: Fragments p5: Communicating events

2012-02-23T15:12:17+00:00

In your Fragment class, if you create listener on a particular interface, and make the parent implement that interface, you can communicate via events.

First create the interface:

public interface OnNewFragmentPressed {

void onNewFragmentPressed();

}

Then create a listener method of that interface.

public static class NewFragment extends Fragment {

private OnNewFragmentPressed mListener;

…

Then in the onAttach() method of your Fragment, use the passed in Activity to make sure it implements the interface, and set the listener to that.

@Override

  public void onAttach(Activity activity) {

super.onAttach(activity);

try {

   mListener = (OnNewFragmentPressed) activity;

} catch(ClassCastException e) {

   throw new ClassCastException(activity.toString() + ” didn’t implement OnNewFragmentPressed”);

}

}

Now you can call methods of that interface, thereby interacting with your parent Activity.

DroidDevelop Stream: P144: Fragments p4: Communicating between FragmentActivity and Fragment

2012-02-23T14:36:50+00:00

In your FragmentActivity, you can call getSupportFragmentManager().findFragmentByTag(“tag”), or findFragmentById(R.id.frag), to access the child Fragment. From there you can call its methods.

Similarly, in the Fragment, you can call getActivity() to get access to the parent FragmentActivity().

Stripeymilk: The long road of becoming an Android 'Top Developer'

Stripeymilk — 2011-06-20T03:42:00+00:00

Hello there! Nearly no mortal on the interwebs knows my work, but that's about to change pretty soon. I'm here with only two goals: to bring more high quality apps to the Android Market and to earn this nice "Top Developer" badge.

To reach those goals, I'll be spending lots of time in front of the notebook, working hard on research, coding, gfx / ui design and marketing. All of that as a single indie developer.

I started out by making my own clone of snake (Yeah, I can hear you sigh right there. Another one? ;) ). The snakes are mostly just for testing the waters though. Eventually I'm going to get at the more original ideas. There's lots of 'em in my notebook for sure and I'm really curious to find out what people think of it!

You can find my current apps at the following url: https://market.android.com/developer?pub=Stripeymilk

Let's get thing started!

ps. Please don't mind the pink colors on this blog. It's the closest to what I'm currently having in mind for the actual design, but it's obviously not going to stay this way :)

Stripeymilk: How not to develop your games for Android - part 1

Stripeymilk — 2011-06-20T04:13:00+00:00

Every once in a while you'll get this genious idea for an app or game. And really, in your own mind, the idea usually is a pure stroke of genious. But some times, that's exactly the point where geniality is about to turn into something completely different...

You're starting to think about how you're going to approach the idea in terms of software development. Is this toolkit the right one for your app? Might that toolkit be the perfect match? Should you rather write your app without any toolkit at all? Will it be native? Will it be Java or C++? Will you want it to be available across different platforms?

Those are the questions that need to be answered on the very first day. For myself, I think cross platform compatibility is quite important because it's a lot easier to use one common code base for multiple platforms. When you fix a bug here on Android, it should often get automatically fixed on iOS as well. Or whatever other system you'd like to write your app for. It can bring down the burden on the indie developer or a small team of developers, which is a great feat if you don't have an unlimited amount of time to spare.

As for native apps, I think the general idea behind it is clear; native can equal less bloat, thus it should be faster and everyone could be happy when they use your app. Right?

..well, not necessarily so much!

I wanted to make my app available on multiple platforms. This includes (obviously) Android, iOS, and maybe even WP7 if the guys and gals from Redmond were to allow for ordinary 3rd party developers to use C/C++. But as with WP7, each of these platforms comes with its own set of limitations.

When starting development on "Turn" I was looking for a way to get my feet wet in multiple areas: markets and app stores, game development and how to get great ratings by delivering (I hope!) on quality.

Luckily, the first person ever to rate my little app gave me all out of the full five stars (actually, it used to be four, but after fixing a little annoyance it suddenly turned into five stars :)). Woah! Now that's how you can truly movitate a developer to keep bringing on the good stuff, thank you so much!

More people started to download the game and more people added five star ratings. One day, I woke up to check out the ratings again. After a bunch of full five star ratings, the worst thing happened: someone rated my game with only one star, without leaving any email, tweet or comment in the Market at all. Oh my.. how was I supposed to figure out why this person did that? Really, it's quite hard to predict why someone would think an app is worth one star when there's not a message coming along with it. I know, it can be a matter of taste and perhaps he or she just did not like the app, but I'm working hard to get my apps as stable and as nice looking as possible within the design. Is it really worth one star, even when a person just doesn't appreciate what it looks like but didn't see it crash or anything?

Then, I started to look into how well my app performed on a multitude of devices. I mean, it did absolutely great on my HTC Desire, but who knows it could run very slowly on other devices. This is where I figured that some devices out there are cheap. Not only are they cheap, they're missing out on a number of very useful features as well. What came most as a shock, is that some recent devices are sold without the ability to render using the hardware, falling back to software rendering. As some of you might already know, software rendering can make things very slow, so there's probably the reason why I got my one star rating. Of course, that's still an educational guess, but I'm hoping it is.

In the end there are two reasons why this could ever happen:

You're using OpenGL ES to render the graphics and specified GLES 1.0 as the minimum requirement. Bad choice. Really bad. It appears that some devices are using a software renderer called PixelFlinger, which doesn't seem to have have any 1.1 or 2.0 features and renders slowly using the cpu instead of the gpu. If PixelFlinger is there, performance is going to be very bad.
You're not (re)drawing only the updated parts of the screen with either OpenGL or the Android Canvas, making the device draw lots more than what would be necessary. Unfortunately, if you're going for cross platform compatibility, it's not possible to use Canvas here because it's not available through the NDK (on Android 2.0, 2.1 & 2.2). Drawing inside selective areas with OpenGL is not a usable option either, because there are so many Android devices out there with different implementations of OpenGL ES. On top of that, Android 2.2 and lower versions do not have support for everything needed to get things working the right way. I'll write more about that in another blog item, as it can become quite a complex issue to tackle.

In the end, if you're going for cross platform compatibility and would like to use OpenGL ES for your app; think again. It might be a better choice to use the native Canvas API instead when you'd like your app to run on as many Android devices as possible.

If you're on a reasonably fast device (that's almost any device out there, with the exception of a few), you might want to check out the result: Turn.

Sean Catlin: jMdns and Android 4.0

snctln — 2012-08-04T00:56:05+00:00

I wanted to post a quick note just in case anyone else runs into this issue or I forget it later on.

jMdns is a great java library to provide zeroconf/bonjour capabilities to your Android application. I was successfully using this in a project up until Android 4.0 “Ice Cream Sandwich” aka ICS, once Android 4.0 devices were starting to be used more often I was receiving user reports that the application was not working. I knew it was a jmdns issue, I just didn’t have an ICS device to be able to track down the issue.

Well I was at Google I/O this year and picked up a few Jelly Bean (Android 4.1) devices. Both of these devices have the same issue that was being reported by Android 4.0 devices, basically the zeroconf functionality was not working.

It took me quite a while to track down but I figured out the problem.

Most jmdns Android tutorials instruct you to create your jmdns object by calling “jmdn.create();”. This works fin in Android 2.x and 3.x, but does not always work with Android 4.x

To fix the issue use the “jmdns.create(String Hostname);” constructor passing in the ip address of your wifi connection which can be obtained from a WifiInfo object from the Android WifiManager service.

Hopefully this helps people in the future, it seems something changed between Android 2.x/3.x and Android 4.x where the default jmdns.create() function is no longer bound to the regular wifi interface.

Sean Catlin: snctlnSoftware is Back!

snctln — 2012-03-27T19:52:26+00:00

snctlnSoftware is Back!

The truth is that I never really went anywhere. I have been staying busy with Android development and have more or less learned what I need to know for iPhone development.

I maintain a full time job as a Mobile Software Engineer at a company where I have been employed either full time or as a contractor for the past 6+ years. I wrote our Android app and I maintain our iPhone app. Objective C and Xcode is a beast, it feels very different that developing Java with eclipse or even C++ with Visual Studio, but that isn’t a problem. Over the past year and a half I have become comfortable doing whatever it is I need to do with iOS programming and have released some good updates to our app.

I have not released a new Android app under snctlnSoftware in years, that will be changing very soon. However, I have been keeping busy with Android programming beyond my day job. Last year I took a contract to develop a port of an iOS program and I find the finished product to be a very usable and handy utility.

Recently I started a new project for my friends over at ThePowerbase, an Android app that lists their stories, basically a nice looking wordpress RSS feed reader. It is shaping up to be a good project, and as always with my code I am implementing it as an Android library. The current state of the library is that it works with just about any WordPress site, just add a few images and use the library t compile a good looking Android app that presents your WordPress site content in a visually appealing manner. I even plan to make use of the library to produce an app for this site, snctln.com

Mart Roosmaa: Entry/exit animations

Mart — 2009-09-20T13:49:14+00:00

When writing FUN2Learn I was presented with a challenge: how to make views animate at the start and end of the activity without creating a big mess in the code. So I created a helper class to negotiate the animations for registered views and have a central place to trigger them.

In the Activity.onCreate() you need to register the views that have entry/exit animations and start the entry animation if the activity is just started:

  View v1, v2, v3;
  AnimationNegotiator negotiator;
  // ...

  @Override
  protected void onCreate(Bundle savedInstanceState)
  {
    animator.register(v1, negotiator);
    animator.register(v2, negotiator);
    animator.register(v3, negotiator);
    // ...
    if (savedInstanceState == null)
      animator.animate(GroupAnimator.ANIMATION_IN);
  }

The GroupAnimator.animate() function can also take a callback as a second argument, which is called when animations end. This is useful for using the GroupAnimator to do exit animations.

To do the exit animation you need to override the Activity.onKeyDown() method and intercept the KeyEvent.KEYCODE_BACK key code, starting the exit animations with the callback to actually close the activity when the animations have ended. You do however want to make the implementation so that when pressing the back button twice it would exit immediately.

The AnimationNegotiator is a simple callback that is used to determine the animation used for each of the visible views. When called, it receives the view in question and the animation type (in/out) as arguments and is expected to return the animation to be used. For instance a simple implementation of this could be:

public class MyActivity extends Activity implements AnimationNegotiator
{
  // ...
  public Animation negotiateAnimation(View v, int animType)
  {
    if (animType == GroupAnimator.ANIMATION_IN)
      return AnimationUtils.loadAnimation(this, R.anim.fade_in);
    if (animType == GroupAnimator.ANIMATION_OUT)
      return AnimationUtils.loadAnimation(this, R.anim.fade_out);

    return null;
  }
  // ...
}

And finally the code for GroupAnimator itself:

package net.roosmaa.types;

import java.security.InvalidParameterException;
import java.util.ArrayList;
import java.util.Iterator;

import android.view.View;
import android.view.ViewParent;
import android.view.animation.Animation;
import android.view.animation.Animation.AnimationListener;

public class GroupAnimator
{
  public static final int ANIMATION_IN = 0;
  public static final int ANIMATION_OUT = 1;

  public interface AnimationNegotiator
  {
    Animation negotiateAnimation(View v, int animType);
  };

  public interface AnimationProgress
  {
    void animationEnded(View v, int type, int stillRunning);
  }

  private class RegInfo
  {
    public View view;
    public AnimationNegotiator negotiator;
  }

  private final ArrayList<RegInfo> regViews = new ArrayList<RegInfo>();
  private Animation defaultIn;
  private Animation defaultOut;

  public void register(View view, AnimationNegotiator negotiator)
  {
    RegInfo inf = new RegInfo();
    inf.view = view;
    inf.negotiator = negotiator;

    regViews.add(inf);
  }

  public void setDefaultAnimation(int type, Animation animation)
  {
    switch (type)
    {
    case ANIMATION_IN:
      defaultIn = animation;
      break;
    case ANIMATION_OUT:
      defaultOut = animation;
      break;
    default:
      throw new InvalidParameterException("Received an invalid type.");
    }
  }

  public void animate(int type)
  {
    animate(type, null);
  }

  private boolean checkTreeVisible(View v)
  {
    if (v.getVisibility() != View.VISIBLE)
      return false;

    ViewParent vp = v.getParent();
    if (!(vp instanceof View))
      return true;

    View p = (View) vp;
    if (p.getId() == android.R.id.content)
      return true;

    return checkTreeVisible(p);
  }

  public void animate(int type, AnimationProgress monitor)
  {
    AnimationTracker animTrk = null;

    if (monitor != null)
      animTrk = new AnimationTracker(type, monitor);

    for (RegInfo inf : regViews)
    {
      if (!checkTreeVisible(inf.view))
        continue;

      Animation anim = null;
      // Negotiate animation for the current view:
      if (inf.negotiator != null)
        anim = inf.negotiator.negotiateAnimation(inf.view, type);
      // Use default if no animation set:
      if (anim == null)
        anim = type == ANIMATION_IN ? defaultIn : defaultOut;
      // If still no animation, don't animate:
      if (anim == null)
        continue;

      if (animTrk != null)
        animTrk.track(inf.view, anim);

      inf.view.startAnimation(anim);
    }
  }

  private class AnimationTracker implements AnimationListener
  {
    private class TrackInf
    {
      public View view;
      public Animation anim;
    }

    private final int type;
    private final AnimationProgress monitor;
    private final ArrayList<TrackInf> inactive = new ArrayList<TrackInf>();
    private final ArrayList<TrackInf> active = new ArrayList<TrackInf>();

    public AnimationTracker(int type, AnimationProgress monitor)
    {
      this.type = type;
      this.monitor = monitor;
    }

    public void track(View view, Animation anim)
    {
      TrackInf inf = new TrackInf();
      inf.view = view;
      inf.anim = anim;
      inactive.add(inf);

      anim.setAnimationListener(this);
    }

    public void onAnimationStart(Animation animation)
    {
      Iterator<TrackInf> iter = inactive.iterator();
      TrackInf inf;
      while (iter.hasNext())
      {
        inf = iter.next();
        if (inf.anim != animation)
          continue;

        iter.remove();
        active.add(inf);
      }
    }

    public void onAnimationEnd(Animation animation)
    {
      Iterator<TrackInf> iter = active.iterator();
      TrackInf inf;
      while (iter.hasNext())
      {
        inf = iter.next();
        if (inf.anim != animation)
          continue;

        iter.remove();
        monitor.animationEnded(inf.view, type, active.size());
      }

      if (active.size() < 1)
      {
        // Active animations over, remove pending inactive;
        // (if the animation doesn't start that most likelly means that the widget is hidden)

        iter = inactive.iterator();
        while (iter.hasNext())
        {
          inf = iter.next();
          if (inf.view.getAnimation() == inf.anim)
            inf.view.setAnimation(null);
        }
        inactive.clear();
      }
    }

    public void onAnimationRepeat(Animation animation)
    {
    }
  }
}

Mart Roosmaa: Thoughts for mobile in 2013 and beyond

Mart — 2013-01-02T22:32:12+00:00

Today Canonical announced the mobile version of Ubuntu. For me as a Linux fan this is very exciting news, however, the developer in me screams: “Not another phone I need to target when writing mobile apps”. I’m surely not the only one thinking that.

Currently the major smartphone OSes on the market are Apple iOS, Google Android (and Microsoft Windows Phone). Upcoming OSes that I know of and follow are: Mozilla’s Firefox OS, Jolla’s Sailfish, Blackberry’s BB10, Samsung’s Tizen and Canonical’s Ubuntu. Some of those will be released this year, other in the following years. Some might not be released at all and new ones will also try to enter the market.

The current generation of devices mostly have a OS specific user experience (with an exception of Android where manufacturers can somewhat customise the experience). The clear trend is that device manufacturers and operators want to differentiate themselves with different user experiences and we (as consumers) also want to have a unique device that separates us from our friends, which fits with our personalities – meaning there is demand and room for different operating systems.

If a new device is to succeed it has to have quite a large repository of apps that the user can use. That can be a taunting task for the newcomers as getting developers to make an app for their device is next to impossible due to the huge costs associated with it. In most cases that process involves rewriting the application from scratch in a different language.

Here is a list of the official languages and native (UI) frameworks for each of the platforms:

Android – Java w/ Android framework
iOS – objC w/ Cocoa
Windows Phone – C# w/ Silverlight
Sailfish – C++ w/ QML
Firefox OS – JavaScript w/ HTML5
BB10 – C++ w/ QML
Tizen – C w/ Enlightenment Foundation Libraries
Ubuntu – C++ w/ QML

As anyone who has been involved in the app developing process knows, it’s a major headache developing two mostly identical apps, but it’s more or less manageable. Developing the app for even more platforms would be infeasible (especially financially).

We need tools, which would enable us to stop writing the same code over and over again for multiple platforms. There are various technologies available which do just that and can be used to create 3rd party apps, the most popular of which is the over-hyped HTML5. Others include Flash (for iOS, Android), .NET with Xamarin’s Mono products (for Android, iOS), various JavaScript based abstraction layers (PhoneGap, Titanium, etc) and the list goes on.

Many see HTML5 as the silver bullet here, but I tend to disagree for a couple of reasons. First the bar for performance was set really high by Apple when they released iOS and currently HTML5 cannot get anywhere near it. It is also quite difficult to get a single sane way of integrating with the device user experience due to the fragmented nature of HTML and browser technologies.

Flash based apps do run fine on iOS and Android, but they lack integration with the look and feel of the underlying device. Meaning the technology is only useful for games, where the user doesn’t expect them to integrate well with the system. There is also a problem of being locked into the platform more than with other technologies – when Adobe decides to discontinue their Flash products (or export to iOS/Android feature) that’s that.

The Xamarin team has brought the powerful C# language and .NET framework to both iOS and Android platforms. They have created bindings for almost 100% of the platform provided APIs, so the applications written using their technologies are as good as the ones written with the official platform frameworks. This means that when targeting multiple platforms (Andorid, iOS or Windows Phone) most of the code, which doesn’t deal with the UI directly, can be reused – resulting in fewer bugs, faster development time and decreased costs while still providing the user with a native performance and look-n-feel they’ve grown accustomed to. And because it’s all based on the open-source Mono project it is all true and tested, it’s fast and stable – even Unity, the powerful gaming engine, uses Mono as it’s internal game logic engine.

The last technology, which promises extensive code reuse, native performance and device specific UX is Digia’s Qt Quick (QML). Most of the new upcoming mobile OS’es use this technology and Digia is committed to enabling the use of this technology on iOS, Android and even Windows 8 devices. The power of Qt Quick is that it separates app code and UI very well, enabling designers to quickly create and experiment with UIs for different form factors and devices. The moment it is available on more than one smartphone platform, this technology will become a serious contender when developing apps for more than one platform, which is one of the reasons why most of the upcoming OSes are using it for their native apps.

And now for some predictions for 2013.

Instead of having to write and maintain several versions for the app in objC, Java and .NET companies and developers will be looking for technologies like .NET/Mono and QML to write performance critical apps and JS/HTML5 to write not-so performance critical apps. Reusing code enables more innovation on the UI side for multiple platforms.

This means that when currently objC/iOS and Java/Android developers are very valuable to companies creating mobile apps, their value will decrease towards the end of the year and .NET/iOS+Android+WP and C++/QML developers will become a sought-after employee in 2014.

There will be many more smartphones which aren’t iOS or Android devices and which will look and feel awesome, they will have access to most Android apps in addition to apps optimised for those devices. The hardware manufacturers, most of whom currently have almost no way to differentiate their offerings, can regain market share and release cool products that the consumers will want to buy. (Except Nokia. Sorry, but you dance to Microsoft’s slow and steady beat now. Maybe next year. Probably 2015 though.)

This also means that the user experience will range vastly from device to device. Giving room for experimentation and much more choice. Apps will be available everywhere and they will fit in and be of better quality. The overall application store concept will transcend platforms and a competition of who can provide the best analytical and developer tooling will start.

And now, lets wait and see what the next 12 months brings us; whatever it is, it won’t be boring!

Notion Ink: Camera and More

vikramdutt9 — 2012-04-07T05:55:55+00:00

Hello,

For a change, it’s not Rohan here. Work on Camera is still a WIP. Code for the camera libraries are closed source with NVidia and getting around the camera sub-system is taking longer than expected.

Having said that, if you are waiting for the camera update, voicing at Tegra Forum might help though most of the questions are either deleted or never replied. Here is one of the dev for Adam voicing for support, but even the last suggestion suggests to move on to OMAP

As the lead for the sw, it is extremely important for us to make sure that the roadmap doesn’t break anything on Adam 1. The only option (and better one) was to opt for RenderScript.

RenderScript is hardware independent (though can be tweaked) and development on RS will make sure that Adam 1 stays in SW support for at least 2 more years.

RenderScript and SVG are going to be in out focus for next two-year here at Notion Ink. Below is a very small sample of RenderScript rendering an A3D model of simple sphere, with Earth Map (from Nasa), bump map created using GIMP, couple of lights and animation (not obvious from an image).

Frankly sharing anything on development on next versions of Eden doesn’t make sense till the camera issue is resolved. That’s the last piece of puzzle, and if you can help sport your voice on that forum, possibly we can fix things faster.

As an ex developer of a leading brand you all know about, it is really fascinating to even absorb the idea of how community has made more than 200 ROM variants for Adam. Unlike Adam 1, there will be no short-cuts for 2. If something not working, it won’t go out. Our roadmap is built for next 4 years, so there will be speed differences. But one thing is clear and that’s what I bring here at NI, great products needs stronger fundamentals, and that’s what we will build first.

Last words on the next generation SW approach. We are approaching the era of micro-apps. Every app cannot be tuned in for a particular user. A doctor may have 15 years of formal education and 25 years of practice, but when it comes to sw, he can’t possible build one. But if see clearly, IDEs and APIs like Android SDK and iOS SDK have worked till now to ease the development of the programmers to attract more developers, making things sometimes as easy as making a “task flow” like an accountant would do, “refer” a value in one cell of a sheet to another cell. There is a truck load of information yet to come, but first things first.

Best

Notion Ink: Back from Hibernation!

Rohan Shravan — 2012-04-05T10:58:46+00:00

Hello All,

We are back from hibernation now! Sorry for the break (much-needed on our end).

Let me know what is flowing across your minds and I will keep you busy reading on weekends!

Regards

Rohan Shravan

NeatPIX: Version 0.1.0.2 is out

NeatPIX Team — 2010-01-30T10:28:51+00:00

This is still a preview version. We've incorporated the support to view pictures from any folder available on the SD card. There's also some improvement on the load time for the first time you run the app.

NeatPIX: First Day in the Market

NeatPIX Team — 2010-01-26T01:29:00+00:00

So this was the first day of the app in the market and we got some feedback on the fact that the application is not loading all the images in the SD card. That's interesting because that actually happens by design. We'll let me explain that... When we were designing the application we had to prioritize some features over the others and we really though at that time that the need to load images out of the images library folder (DCIM) was not going to be a very usual condition, well, turns out we were wrong. So please rest assured that we're moving things around and this is going to be available pretty soon.

Skyler Slade: A simple introduction to the Android framework

Skyler Slade — 2011-03-04T06:18:39+00:00

Some of the more common questions that I see posted to various Android development forums are from developers curious about, or new to the platform, and looking for a good, light introduction to it all. This is my best attempt at a thorough, simple summary.

An Android application should be thought of as a package comprised of separate, loosely-coupled components connected at runtime, not as a single executable. These components work together by responding to events, or Intents, that are broadcast by other components included in an application, or by the Android system. Each Android app has a “manifest” file, AndroidManifest.xml, that lists each component that an app includes, and which Intents, if any, will trigger these components to do work.

Intents

In its simplest form, an Intent contains an “action” string, which is usually represented as a Java package name prefixed to something like “action.COMMAND_NAME.” An Intent action might be “com.example.action.DOWNLOAD_LATEST_WEATHER,” for example. Many framework components are capable of broadcasting an Intent, and likewise many framework components are capable of registering to receive these broadcasts. To be notified when a particular Intent is broadcast, an application can create a BroadcastReceiver that listens for the broadcast of a specific Intent action. Intents are really just a way of connecting callbacks.

An Intent can also contain a Map of key-value pairs that is sent along as “extras” when the Intent is broadcast. Like the value 32601 for the extra “userZipcode.”

Services and BroadcastReceivers

These separate framework components work together to support Android’s multitasking model because - among other things - they allow parts of an application to do work even when the user is doing other things, like checking his email or browsing a web page.

To give an example, BroadcastReceivers allow apps to be notified when the phone’s SD card is mounted, or when a text message is received, even when the app, or package, to which the component belongs is not in the foreground. Likewise, Services allow an app to perform long-running tasks in the background, like playing music. Services and BroadcastReceivers can be combined to create an application that performs a task triggered by a system event, like downloading the latest weather report when the phone’s location changes.

Note that Services allow applications to do work in the background only in the sense that an application is doing work without any of its Activities being open and visible to the the user in the foreground, though this work is still being done on the app’s main, or UI, thread. It’s important to understand that all framework components, and almost all SDK-provided framework component instances, run on the main thread. One exception that I’m aware of is IntentService, which is useful if you want to perform a task in the background, on a background thread.

Activities

As alluded to, Activities are the parts of an app that users can see and with which they may interact. An Activity has a view which is built from xml that you create, and it can contain widgets like buttons, text input fields, date pickers, and other common user-interface components. It also contains these views’ click-listeners and any other supporting code. Activities allow an application to show AlertDialogs, ProgressDialogs, Toast notifications, and other things that can be used to grab a user’s attention or prompt him for input. Using callbacks that you may override, Activities can have menus that are activated by the phone’s “menu” hard-key, and list items can have long-press, or context, menus.

ContentProviders

ContentProviders are used to make an application’s data available to other apps on a user’s phone. A scheduling app might make its appointments available to be read by other applications, using a ContentProvider.

Putting it together

You can use as many of these components in your application, or package, as you like: there’s nothing in the framework that restricts you to using one single Activity, or even one single Service, and there’s nothing in the framework that requires you to use any components that you don’t need. For example, the Grooveshark app has 31 Activities, 3 Services, many BroadcastReceivers, but no ContentProviders.

As a person uses an Android app, they navigate from Activity to Activity, just as they might browse a series of pages on a web site. And just like URL arguments or forms are used to send information from page-to-page, Android apps use Intent extras to send things between Activities. Just as a person might leave a web site at any time, a user of an Android app might leave, or pause, the app at any time by pressing the phone’s “home” hard key. The framework provides callbacks that you may override in your Activity instances, letting you save and resume state when this happens.

Undoubtedly, parts of the Android framework documentation can be overwhelming and confusing, but the basics don’t have to be. The SDK documentation has improved immensely over the past year, and I’ve no doubt that it will continue to get better going forward.

For a more in-depth discussion of framework components and their usage, the SDK Application Fundamentals doc is an absolutely fantastic resource, which you can read at http://developer.android.com/guide/topics/fundamentals.html. If you’re still curious about Android development, read through this a few times and really be sure that you’ve got a good understanding of the basics before you move on to any advanced concepts.

Good luck writing apps!

Skyler Slade: Sharing complex Dialog interactions across multiple Activities

Skyler Slade — 2011-02-09T02:31:42+00:00

One of the more common problems that I have run into in Android application development is how to reuse complex, multi-step dialog actions across multiple activities while avoiding code duplication.

In the Grooveshark Android app, several instances of Activity and ListActivity give the user the option to add a song to a playlist. Choosing to add to a playlist starts a multi-step series of Dialog actions: the user is asked if they want to add the song to an existing playlist, or to create a new playlist. If the user chooses to add to an existing playlist, they’re presented with a radio-list of their playlists, otherwise they’re asked to enter a name for their new playlist. After entering a name and pressing save, a ProgressDialog is shown while a network request is made to create the playlist through Grooveshark’s API. If the user chooses to add a song to an existing playlist, a network request is then made to the Grooveshark API to add the song to the playlist, spawning a ProgressDialog.

As a rule, when making any network requests from the app, a “cancelable” indeterminate ProgressDialog must be shown. If the user cancels the operation by pressing their phone’s “back” hard-key, the network request should be canceled immediately, and any resources freed. Additionally, all dialogs must respond to application configuration changes—like an orientation change—and any ongoing network requests must survive these configuration changes, too.

This “add to playlist” interaction requires eight dialogs:

“Create new playlist or add to existing” AlertDialog
An AlertDialog for entering a new playlist name, or
A ProgressDialog shown when loading a user’s list of playlists, and,
An AlertDialog with single-choice items for picking a playlist from the user’s list of playlists
A ProgressDialog shown when creating a new playlist and saving a song to this playlist, or
A ProgressDialog shown when adding a song to an existing playlist
An AlertDialog shown when creating a new playlist fails, or
An AlertDialog shown when adding a song to an existing playlist fails

This process uses three separate AsyncTask instances:

Loading the logged-in user’s complete list of playlist names either from a network request or from the local database
Creating a new playlist and adding a song to it
Adding a song to an existing playlist

This is a complex set of interactions that totals around 600 lines of code, and this set of interactions needs to be launched from nearly every Activity in the Grooveshark application.

Most of these activities are instances of ListActivity—the user’s list of favorite songs, popular songs, cached songs, playlist songs, song search results, etc.—so this Dialog and AsyncTask code could live in a base ListActivity class from which all other list activities derive. The Grooveshark application does make use of a base ListActivity class that provides a common context and option menu, but not all activities needing the “Add to Playlist” feature are instances of ListActivity but not all activities needing the “Add to Playlist” feature are instances of ListActivity; “NowPlaying”—our player and queue Activity—is a notable example.

Composition could be used to give each Activity needing “Add to Playlist” functionality these dialogs and AsyncTask instances, but this would require a litany of cumbersome callbacks to connect the host activity’s lifecycle callbacks to our proxy object—callbacks like onCreateDialog() to create our eight dialogs, and onRetainNonConfigurationInstance() to keep a reference to any active AsyncTask instances across Activity configuration changes.

My ideal solution to this problem:

Does not unnecessarily duplicate code
Does not use object inheritance
Does not use object composition
Encapsulates all Dialog creation and display code
Encapsulates all relevant AsyncTask code
Can be launched from any application Activity
Can respond to all Activity lifecycle methods

The solution I’ve found that fulfills all of our requirements uses a single transparent Activity instance to handle all related Dialog steps. This host Activity contains all Dialog code in onCreateDialog()—and onPrepareDialog(), if necessary—and encapsulates all of its network requests and database interactions in member AsyncTask instances. I call this the “transparent dialog-host activity” pattern, and the Grooveshark app uses this for its “Add to Playlist” feature, and in other places.

Transparent Dialog-Host Activity

I’ve put together a demo application to demonstrate how to use this pattern. It’s a simple to-do list app that let’s you create and edit to-do items. The demo app has two ListActivity instances and one transparent Activity instance that hosts its dialogs. We’ll walk through the important parts, and you can grab the entire source from the GitHub repo.

Getting Started

First create the Activity to contain your Dialog instances. In the demo application I linked to, this is the DialogTasks.java file. All dialogs are activity-managed, which means that on configuration change, Android handles dismissing and reopening any dialogs that were open before the configuration changed occurred.

It is always best to use managed dialogs; do not create and show dialogs on your own, always use onCreateDialog(), onPrepareDialog(), showDialog() and dismissDialog() or removeDialog(). Showing and dismissing dialogs without knowledge of and the ability to respond to lifecycle and configuration changes can be extremely error-prone and will crash your entire application if you do it wrong.

In DialogTasks.java we first define our dialog id constants:

private static final int EDIT_NAME_DIALOG = 0;
private static final int EDIT_DATE_DIALOG = 1;
private static final int CREATE_NEW_DIALOG = 2;
private static final int SAVING_DIALOG = 3;
private static final int DATE_PICKER_DIALOG = 4;
private static final int CONFIRM_DELETE_DIALOG = 5;
private static final int DELETING_DIALOG = 6;

And we define our dialogs in our activity’s onCreateDialog() method. Our demo program uses seven dialogs: a DatePickerDialog for choosing your to-do item’s due date, four AlertDialog instances for collecting input and showing a confirmation prompt, and two ProgressDialog instances that we show when saving changes.

/**
 * Lifecycle method invoked to create a dialog shown via showDialog()
 * NOTE: we override the older, deprecated method so that we can work
 * on older sdk versions.
 */
@Override
public Dialog onCreateDialog(int which)
{
    if (which == EDIT_NAME_DIALOG) {
        final View dialogView = getLayoutInflater().inflate(R.layout.new_task_dialog, null);
        AlertDialog dialog = new AlertDialog.Builder(this)
            .setView(dialogView)
            .setTitle(R.string.edit_task_title)
            .setPositiveButton(R.string.save, new DialogInterface.OnClickListener() {
                @Override
                public void onClick(DialogInterface dialog, int id)
                {
                    String name = ((EditText) dialogView.findViewById(R.id.task_name_edit)).getText().toString();
                    ToDoList.ToDoItem toDoItem = new ToDoList.ToDoItem(name,
                            currentToDoItem.year,
                            currentToDoItem.monthOfYear,
                            currentToDoItem.dayOfMonth);
                    ToDoList.getInstance().remove(currentToDoItem);
                    ToDoList.getInstance().add(editedToDoItem);
                    showDialog(SAVING_DIALOG);
                    // Normally this would start an AsyncTask to make a network request or
                    // to write to a local database, but for this demo I'm using a Handler
                    // on the main thread to simulate the delay of sending a network request
                    // and waiting for its response.
                    handler.postDelayed(new Runnable() {
                        @Override
                        public void run()
                        {
                            Toast.makeText(DialogTasks.this, R.string.task_updated,
                                    Toast.LENGTH_SHORT).show();
                            setResult(RESULT_OK);
                            finish();
                        }
                    }, 3000);
                }
            })
            .setNegativeButton(android.R.string.cancel, new DialogInterface.OnClickListener() {
                @Override
                public void onClick(DialogInterface dialog, int id)
                {
                    setResult(RESULT_CANCELED);
                    finish();
                }
            }).create();
        return dialog;
    }
}

Rather than post the entire onCreateDialog() implementation from the demo, which is a bit lengthy, I’ve only posted an excerpt so that I can point out a few key things. Note that for both the “save” and “cancel” buttons, in their on-click listeners we set an activity result code via setResult() and we call finish() to end our containing Activity. DialogTasks.java can be launched with startActivityForResult(), as it is from our demo’s ToDoListActivity.java, and in this instance, the result code from DialogTasks.java is used to update its list.

It’s important to finish() your dialog activity from any “last step” of your dialog actions. If you do not invoke finish() when the last Dialog closes, a user of your application will be able to see whatever activity instance was open before the dialog activity launched, but they will not be able to interact with it–it will not receive any touch or menu events until the phone’s “back” hard-key is pressed.

DialogTasks.java supports four work-flows: creating a new to-do item, editing its name, editing its due date, and deleting a to-do item. To pick which work-flow, or task, to start, we use extras in the Intent used to start our activity.

These Intent extras are defined in DialogTasks.java

/**
 * Extra sent to create a new ToDo item
 */
public static final String CREATE_TODO_EXTRA = "createToDo";
/**
 * Extra sent to edit an existing ToDo item's name
 */
 public static final String EDIT_TODO_NAME_EXTRA = "editToDoName";
/**
 * Extra sent to delete an existing ToDo item
 */
public static final String DELETE_TODO = "deleteToDo";

And DialogTasks.java can be launched from any other Activity like so:

Intent i = new Intent(this, DialogTasks.class);
i.putExtra(DialogTasks.CREATE_TODO_EXTRA, true);
i.addFlags(Intent.FLAG_ACTIVITY_NO_ANIMATION);
startActivity(i);

Note that when starting our dialog-host activity, we disable Android’s transition animation with the Intent.FLAG_ACTIVITY_NO_ANIMATION flag. Without disabling the transition animation, the first Dialog opened from our transparent Activity would appear to open with an activity’s animation rather than the usual Dialog animation. On stock Android 2.x—API level 5—the dialog would appear as it slid-in from the right. This flag is only available on API levels 5 and higher, but luckily on stock Android versions prior to API level 5, the Activity transition animation is the same zoom-in effect used when opening activities, so the extra animation isn’t noticeable.

In DialogTasks.java we check which extras are set, and start the specified work-flow by displaying the first dialog of the task.

@Override
public void onCreate(Bundle inState)
{
    super.onCreate(inState);

    Bundle extras = getIntent().getExtras();
    if (extras != null) {
        currentToDoItem = extras.getParcelable(ToDoList.ToDoItem.TODO_EXTRA);
        if (extras.containsKey(CREATE_TODO_EXTRA)) {
            showDialog(CREATE_NEW_DIALOG);
        } else if (extras.containsKey(EDIT_TODO_NAME_EXTRA)) {
            showDialog(EDIT_NAME_DIALOG);
        } else if (extras.containsKey(DELETE_TODO)
                && extras.containsKey(ToDoList.ToDoItem.TODO_EXTRA)) {
            showDialog(CONFIRM_DELETE_DIALOG);
        } else {
            finish();
        }
        /*
         * Overwrite our Intent's original extras so that on configuration
         * change we do not create duplicate, overlapping dialogs. Recall that
         * on configuration change, Android will re-create and show any
         * already-open managed dialogs.
         */
        Intent intent = getIntent();
        if (intent != null) {
            intent.replaceExtras((Bundle) null);
        }
    }
}

Note that we replace our activity’s getIntent() extras with an empty Bundle. As mentioned in the source code comments, it’s important to replace these extras because on configuration change, the original Intent is re-delivered to our new Activity instance.

Recall that when using activity-managed dialogs, Android handles removing and re-displaying any open Dialog instances on configuration change. If we do not replace our activity’s Intent extras, when this event occurrs, overlapping dialogs will be shown: both the initial dialog opened in onCreate() by one of our Intent extras, and the re-displayed Dialog that was previously closed by Android.

Finally we make our Activity transparent and and remove its title bar by specifying styling options in AndroidManifest.xml.

<activity android:name="DialogTasks"
          android:theme="@android:style/Theme.Translucent.NoTitleBar"
          android:noHistory="true" />

A Caveat

So far the only thing that doesn’t work as you would expect it to when displaying dialogs in this way is that the underlying activity’s options menu is not shown when the phone’s “menu” hard-key is pressed. This is because the foreground, transparent Activity has focus, so all key events are delivered to it. This hasn’t yet been a problem in the Grooveshark app.

When to use this pattern

Any time you have a set of dialogs that are part of a “wizard-like” process–moving from step 1.) to step 2.), collecting user input and showing different dialogs in response to user input—if this functionality is needed from multiple Activity instances, it’s a good place to use transparent dialog-host activities. If you only need to show these dialogs from a single place in your app, this pattern isn’t a good fit. Additionally if you need to display only a single Dialog from multiple Activity instances, you should bite the bullet and define all of your Dialog code from within each individual activity’s onCreateDialog() method.

Don’t forget to grab the source code and have fun!

Android from Scratch: My emulator looks different than in the examples!

luke — 2009-12-09T00:22:28+00:00

Illustrations of emulator usage in books and on the web have emulator skins that look like devices, but if your SDK is at all recent, the emulator doesn’t look like that – the screen is bare. This is a seemingly insignificant thing, but strangely no one seems to talk about it. I didn’t find any documentation explaining this – I had to ask like a n00b on the IRC channel. Well, to save you the embarrassment – it’s pretty simple. For the API 1.5 and before, the emulator looks like a device. For 1.6 and after, it doesn’t. If you really want your emulator to look like that, you need to use an emulator targeted at 1.5 or before – as far as I can tell, there’s no setting you can use to configure 1.6 or 2.0 to show the device skin from 1.5.

Emulators for versions 1.5 and 1.6

Android from Scratch: Attaching Android platform source in Eclipse

luke — 2010-01-18T17:19:26+00:00

Are you tired of seeing this when you look at your platform JAR in Eclipse?

Dude, where's my source?

Or how about this when you’re debugging?

How am I supposed to debug this?

Android is open source, right? So how do we see the source?

Some background

Tip: If you’re just here to get it working and don’t care where it came from, you can skip on a bit.

This article summarizes and augments three other posts that spelled out how to get the source and use it. It is surprisingly difficult to get your hands on the correct version of the source you need for this purpose, so in addition to describing that process I’m providing the end result for your convenience.

My sources

My three source posts are:

View Android Source Code in Eclipse by Dr. Michael Forster of Google
Browsing Android Source in Eclipse by Eric Burke
Get source from the Android Open Source Project

Both the posts and the comments were very helpful, but somewhat out of date now. How to put it all together?

Getting the right code

The source is all available, but it’s spread out among several projects which put together constitute the Android Open Source Project. Thus I needed to install the repo tool (as described on the “Get source” page) in order to pull down all of the relevant git repositories. The articles describe getting the latest code – the trick is getting the code specific to the platform version you’re working on; at the time everyone was working with 1.0!

When you sync the Android repos, you’ll see output describing the available branches and tags something like this:

 * [new branch]      cupcake    -> korg/cupcake
 * [new branch]      cupcake-release -> korg/cupcake-release
 * [new branch]      donut      -> korg/donut
 * [new branch]      donut-release -> korg/donut-release
 * [new branch]      eclair     -> korg/eclair
 * [new branch]      master     -> korg/master
 * [new branch]      release-1.0 -> korg/release-1.0
 * [new tag]         android-1.0 -> android-1.0
 * [new tag]         android-1.5 -> android-1.5
 * [new tag]         android-1.5r2 -> android-1.5r2
 * [new tag]         android-1.5r3 -> android-1.5r3
 * [new tag]         android-1.5r4 -> android-1.5r4
 * [new tag]         android-1.6_r1 -> android-1.6_r1
 * [new tag]         android-1.6_r1.1 -> android-1.6_r1.1
 * [new tag]         android-1.6_r1.2 -> android-1.6_r1.2

This list generally contains some other random stuff and varies by project. The tags seem to be logically named and standardized across projects, but I couldn’t find how to get the repo tool to pull source based on a tag (if someone knows, by all means comment below). Repo takes the -b option to specify a branch however, and the cupcake / donut / eclair branches are universal, so those are what I used to make the source archives linked in this article, e.g.:

repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake
repo sync

Of course, branches are generally moving targets, so caveat emptor.

Assembling the code as Eclipse expects it

If you follow the above and have a good connection and some patience, you’ll eventually have a directory full of some 2GiB of “stuff,” some of which is the source code you’re looking for. But Eclipse needs just the source, in just the right place. Forster’s post “View Android Source Code in Eclipse” provides a python script for rounding up the source code and creating a nice zip archive out of it, and Burke’s post “Browsing Android Source in Eclipse” describes how to figure out where to put it – in a “sources” directory created underneath the SDK platform directory. Other comments on those posts are helpful for coercing Eclipse to recognize that the source is available.

What you came here for

Without further ado, here’s how you attach source to your platform classes. N.B. all screenshots are from Eclipse 3.5 “Galileo” – other versions may differ significantly.

Download source

Download the zipped source code that I’ve gathered for each platform you are developing for.

Put the source in place

For each platform, create a folder “sources” under that platform (e.g. sdk/platforms/android-1.5/sources) and unzip the source code into it. Then refresh your project (select project and press F5 or right-click and select “Refresh”).

Right click on the project and refresh

Voila, you should see the source!

YES, I SEE the SOURCE!

Getting the debugger on board

I found that even after I’d placed sources in the platform, if I was debugging and ended up deep in the platform (In this case, with an exception), the debugger might not show the code:

Sometimes the debugger still won't show the source

However, it’s fairly straightforward to fix this. Just click on that “Edit Source Lookup Path” button to add a source lookup path. In that dialog leave “Default” selected and click “Add.”

In the following “Add Source” dialog choose “File System Directory” and hit the OK button:

Then choose the source directory where you unzipped the code. The debugger should now show all the code you can debug into.

Source in the debugger... which may or may not help you figure out what went wrong; in this case, a layout error caught at runtime.

A word of caution, though: Eclipse’s debugger seems to think that once you’ve set a source lookup for one project, it’s relevant for all of them. If you’re using different platforms for different projects, you’ll want to change the source it uses. You can do that by right-clicking on the project in the debugger and choosing “Edit Source Lookup” to repeat this process.

Getting back to source lookup in the debugger

Patches welcome

Hopefully this guide makes attaching source easy for you. If the code provided here seems out of sync with the platform when you’re debugging, let me know. If someone knows a better way to pick out the exact code for the different platform versions, comment below. If I’ve slightly (or utterly) misrepresented something, correct me. If you’re just happy to finally see your source, I’d be glad to hear about it!

http://source.android.com/download/

Bolting Android Apps Together: The Android Vertical Line Problem

Todd Folsom — 2012-12-06T18:58:29+00:00

Getting a thin vertical line to use as a divider or other indicator is surprisingly difficult. Various solutions to this problem have been offered at Stackoverflow, e.g. “Android vertical line XML“. Recently I needed a vertical line to use as a divider between items in an open source tooltip component. The default divider was provided as a narrow Textview with a gray background and no text, which was contained within a RelativeLayout. That’s a rather heavyweight implementation, and the divider did not extend the full height of the tooltip, either.

I tried several of the approaches outlined in the Stackoverflow post referenced above and elsewhere. These included a rotated shape drawable and a view with a layout width of 2 pixels, but these did not work. Usually I got a result like below, where the gray divider view caused the tooltip to expand in size and the divider crowded the remaining items out of the tooltip. (An item is made up of text and an icon, like the “Next” and down arrow, although each is optional. See below.)

I then adapted a technique we’d used before to get a divider appearing in TextViews used as table cells. We subclassed the TextView and overrode the onDraw method. We drew a narrow vertical line at the left edge to make a nice divider between adjacent table cells. Here’s the (somewhat condensed) code:

private Paint paint = new Paint();
private void init(Context context) {
	paint.setColor(context.getResources().getColor(
			R.color.cell_divider_line));
	paint.setStrokeWidth(0f);
	paint.setStyle(Paint.Style.FILL);
}
protected void onDraw(Canvas canvas) {
	super.onDraw(canvas);
	canvas.drawLine(0, 0, 0, getHeight(), paint);
}

This tooltip component supports both horizontal and vertical orientations so dividers are needed for both cases. The original views for each orientation had a RelativeLayout as the outer view that contains a single tooltip item (an icon and text), so I subclassed RelativeLayout, as below (condensed). This RelativeLayoutWithDivider class provides for a right divider, a bottom divider or no divider.

public enum DividerOrientation  {RIGHT, BOTTOM, NONE}
private Paint paint ;
private Context context;
private DividerOrientation orientation = DividerOrientation.NONE;

private void init() {
	paint = new Paint();
	paint.setColor(context.getResources().getColor(
		R.color.cell_divider_line));
	paint.setStrokeWidth(3f);
	paint.setStyle(Paint.Style.FILL);
}

@Override
protected void onDraw(Canvas canvas) {
	super.onDraw(canvas);
	switch (orientation) {
           case RIGHT:
         	init();
            	canvas.drawLine(getWidth(), 0, getWidth(), getHeight(), paint);
                break;
         case BOTTOM:
        	init();
           	canvas.drawLine(0, getHeight(), getWidth(), getHeight(), paint);
         	break;
           default:
         //no divider line
              break;
	}
}

public void setDividerOrientation(DividerOrientation orientation) {
	this.orientation = orientation;
}

Logic in the method the populates the items in the tooltip determines which enum to pass on a call to setDividerOrientation such that single items don’t show a divider nor does the last item. (That method is found in the QuickAction class of the open-source project.)

This will make more sense when I show the layout XML for a horizontal tooltip item. Here the parent view is our subclassed RelativeLayout. Nothing had to change in this XML save the class name in the outermost tag.

Bolting Android Apps Together: Fixing The Command File For Android’s uiautomatorviewer Tool

Todd Folsom — 2012-11-27T15:26:16+00:00

The uiautomatorviewer is a “GUI tool to scan and analyze the UI components”, and was made available in Revision 21 of the Android SDK Tools. The instructions for running the tool tell us to open a terminal window, navigate to <android-sdk>/tools and run the “uiautomatorviewer” command. On Windows, that is a command file with a “bat” extension.

The UI for the tool opens up and the instructions tell us next to capture a screen for analysis. Unfortunately this failed for me. The error message implied that the Android adb tool is not installed. It most certainly is installed, so I began a search for a solution. I didn’t find a solution initially, although I did find that other developers were seeing the same problem.

It was when I decided to search on Google+ that I found this post by Endian Ogino. He worked out that the com.android.uiautomator.bindir property, being passed as a Java argument, was blank. Once he edited uiautomatorviewer.bat to supply the path to the <android-sdk>/tools folder, the screenshot action started working. Since his solution did not appear in a traditional Google search, I thought I’d write about it in this blog so that, hopefully, it could turn up in searches more often.

Now, can anyone help me understand why many of the attempts at screenshotting various views in my application fail to generate any XML for display? I’ve searched on the error message and the exception name without any luck.

Eclipse Source: Post Google I/O: The State of Android Development [UPDATED]

Moritz Post — 2013-05-28T10:36:48+00:00

A few weeks ago i posted an analysis of the current state of the gradle based Android build system. Today we are living in a post Google I/O 2013 world and several things have changed. Time for an update. The most prominent change is the new Android development environment: Android Studio.

Android Studio

Currently in its infancy at version 0.1, the new IDE is based on the (free) community edition of IntelliJ IDEA. IntelliJ is widely accepted as a very good Java IDE and has lots of followers. IntelliJ provided Android support itself but this has now been replaced with the “official” extensions provided by Google. Watch the Google I/O talk about Android Studio for more details. The interesting question is: Why did Google invest in yet another development environment next to the Eclipse ADT? After all you were able to download a standalone runnable version of the ADT as well. “People close to the matter” cite several reasons for such a step.

IntelliJ is a great IDE

Obviously i am working for a very Eclipse centric company. Nonetheless i must admit that there is a lot to love about IntelliJ. While the Eclipse Java development components have not seen a lot of innovation lately, IntelliJ keeps on pushing usable features. Better autocompletion, better suggestion prediction and a more flexible editor system helps to boost productivity. In addition several features of IntelliJ/Android Studion go beyond what Eclipse/ADT offers. To name a few:

Resource Inlining (Also works for images)

Implementation folding (Similar to Lambda expression in Java 8)

Parameter prediction (Correct constants are proposed for int parameter)

The features described here will eventually become part of the Eclipse/ADT framework but at the moment this is not the case. In addition Android Studio offers superior visual layout editing and preview features, full gradle project configuration, support for build flavors etc.

On the other hand, many features that developers are used to from the ADT are not yet (natively) in Android Studio: All DDMS tools, dumping the layout hierarchy for the UI Automator etc. These features will be implemented in future releases.

The Android build story is broken (on Eclipse)

While Eclipse is able to compile and export an Android app, it has no idea of a build system. Building Android projects was and still is a mess. Google realized that and started developing a new build infrastructure based on gradle. The new build system strives to unify the project setup in a development environment as well as on a build server. Both scenarios should be driven by one configuration that is very customizable for various product scenarios (free vs paid app etc.). Gradle provides a great foundation for this undertaking and the build system it is on its way to maturity.

While the approach is great in theory, it posed a problem when integrating the system into Eclipse. Since gradle is supposed to completely build the project, the continuous incremental compiler of Eclipse had to be circumvented. This turned out to be a technical challenge that was hard to overcome.

With IntelliJ, the compiler only kicks in when you “make” an application, which made the IntelliJ integration simpler. In addition gradle (and maven) are already first class citizen and so it was much easier to integrate the build hooks into IntelliJ. Side note: In Android Studio gradle runs on hot-standby so it kicks in much quicker than simply invoking a build manually.

Jetbrains (the company behind IntelliJ) supported Google in the integration process and made adjustments for them when necessary. The result is build story which is able to cover the entire round trip from project creation to a release build on the build server. On the way you get: import and setup in the ide, dependency management, awareness of build types and product flavors, export from the IDE and the ability to query your build scripts (a gradle feature).

Gradle Build

Okay, the Android Studio is new and is fully compatible with the the gradle build. But is there anything new in regards to the gradle build itself? In fact there is:

The most interesting feature is the creation of the “Android SDK Build-tools” as part of the Android SDK. The Build-tools contain the commands to compile and package an Android application. The Build-tools are versioned so you can specify what version of the tools you want to use right inside your gradle build script. No more broken builds because you updated your Android SDK.

Another addition is the support for ProGuard. Obfuscating your code is now part of the build tasks.

While more and more features are being supported, there are still features missing like support for the NDK to build native code or support for ecl emma.

Android Library Dependencies

Since hardly any app is an island of solitude you will want to use external libraries to help you with common tasks. An Android library project allows you to do just that. But keeping external dependencies in your ide is cumbersome and obtaining your dependencies from maven is much more elegant. With the aid of the m2e and android-m2e Eclipse plugins this also works reasonably well in Eclipse. Where this approach falls short is when consuming Android libraries via maven. Maven packages those artifacts into “apklibs”. They can be consumed when “mvn install”ing your app without a problem but inside eclipse the apklib format is not supported. This leads to the problem that you have to keep the source project in the ide as well.

In a gradle build, dependencies can be both local files or maven/ivy artifacts. The gradle build introduces a new packaging format for Android library projects called the Android Archive (.aar). This format is pretty new (imo not fully finalized) and not widely adopted yet. While the .aar is the future, the maven apklib is the present and this leads to the following problem: The gradle build does not support the apklib format. So for now you can not consume any Android libraries from maven central in your gradle build. Regular java jar dependencies can be consumed without a problem.

Another problem that has not been solved in the gradle build yet is the ability to consume libraries from the Android SDK. The Android SDK ships with many useful libraries from Google like the support-library, admob, analytics, play services etc. Several of these artifacts ship as Android Library projects that can only be consumed in a gradle build when copying the entire project with source. When using maven, one can use the maven-android-sdk-deployer to copy these resources into the local maven repository but no such thing exists for gradle. The solution that Google is planning to implement is to upload these artifacts to maven central in the .aar format. Thereby they can easily be consumed by a gradle build. Why this hasn’t happened yet is hard to say. Maybe because the .aar format is not finalized? Or maybe Google has other priorities?

[UPDATE] As of 30.05.2013, the support library and the google services are bundled in the Android SDK as .aar maven dependencies. They can be easily consumed within your gradle build script like any other maven dependency.

Wrap Up

Google I/O 2013 brought a lot of new stuff into the Android development landscape. Surely the Android Studio is the star of the show but at the end of the day the gradle build is more important. It provides the underpinnings to unify the Android development story. In that regards one important feature of the gradle build story is still missing: Google has to publish the core components of the Android SDK to maven central as .aar archives. This will be a strong signal for other libraries to also publish as .aar archives. Until that happens the gradle build will remain a patchwork project.

The Android Studio is an impressive new part of the Android development story – many people had been asking for IntelliJ support. The multitude of features that already go beyond what Eclipse/ADT offers makes for some exciting prospects. At version 0.1 it is very early to adopt it fully for existing larger projects but for smaller endeavours it feels very usable. Google plans to push weekly updates of the Android Studio so glitches will get ironed out pretty quickly. Where does that leave Eclipse/ADT? Google has committed to maintaining both development platforms in parallel but it remains to be seen how long that promise keeps up. At least the gradle build support will be integrated soonish.

Leave a Comment. Tagged with android, android studio, Gradle, intellij, android, android studio, Gradle, intellij

Galaxy Tab Review: Download Galaxy Tab Plus CM10.1 P6200, P6210, T869

Galaxy Tab Review — 2013-05-27T10:23:13+00:00

CyanogenMod 10.1, more popularly known as CM10.1 has been successfully ported to Galaxy Tab Plus. There are some issues though. For example – USB mounting of internal storage does not work. Other things that does not work include HDMI, IR blaster, Bluetooth and phone calls crash often. In short, CM10.1 is far from reliable and [...]

The post Download Galaxy Tab Plus CM10.1 P6200, P6210, T869 appeared first on Galaxy Tab Reviews, News, Updates.

Bill Lahti: Two Progress Bars for Android

blahti — 2013-05-23T10:19:33+00:00

I built two different views to show progress bars in Android. One is a horizontal progress bar and the other is a vertical progress bar, made up of a stack of horizontal bars. Here they are displayed in a demo app, running on a Galaxy Nexus phone. For the horizontal progress, you can control the colors used, the width and height of the bar, and the number of divisions. For the vertical progress bar, I wanted it to look like a stack of bars. When you run the demo app, you can see the values change by touching a progress bar. Complete source code is provided below.

SlideME: SlideME has launched the newly designed SlideME Market app v5

SlideME — 2013-05-02T17:50:09+00:00

We have launched our newly designed Android market app, version 5 of the SlideME Application Manager (SAM), and we wanted to highlight some of the new features that you might not yet know about in the new SAM 5.

Thanks to community and tester effort, SAM 5 has already reached its 13th version (5.13) with tons of stability, performance, and usability improvements, easily making it the best SAM (yet).

Eclipse Source: State of the Android Gradle Build System

Moritz Post — 2013-05-02T11:48:28+00:00

Building an Android project can be challenging at times. The Android SDK ships with a set of helpful ant scripts, but has its shortcomings. It mainly lacks a well-populated dependency infrastructure similar to what maven offers (ivy doesn’t count). Hence, the natural evolution of build process spawned the maven android plugin. The plugin allows you to infuse maven artifacts and perform the necessary build steps to package your app. Although maven has a great artifact repository, it has a pretty rigid set of configuration settings. The pom files tend to get verbose and interfering with the designated build process lacks flexibility.

The “New Build System”

Entering the “New Build System” based on Gradle. The new build system is supposed to become the official mechanism for building Android applications. The gradle-based build combines some of the strengths of ant and maven (flexible architecture with a lot of custom tweaking opportunities), whilst at the same time providing reasonable default configurations to keep the build scripts small. Maven dependencies can be consumed from maven central, while it is also easy to consume “local file” dependencies.

Okay, but how does the “New Build System” prevail in practice?

Using the Gradle Android Build

DISCLAIMER: We are only a few days away from Google IO 2013 so the points raised here might have already changed when you read this.

Basic build scripts can be really really small when you rely on the default folder structure for your project. Your basic gradle build script can look like this:

buildscript {
  repositories {
    mavenCentral()
  }
 
  dependencies {
    classpath 'com.android.tools.build:gradle:0.3'
  }
}
 
apply plugin: 'android'

In fact the buildscript{} element is only required to bootstrap the script itself. The actual content is the lonely apply plugin: 'android'. Running this script produces a fully runnable unsigned apk.

The basics are simple but what about dependencies? As I mentioned, you can easily add dependencies from maven central or a local file. In fact, the buildscript downloads its own android tasks from maven central.

repositories {
    mavenCentral()
}
 
dependencies {
    compile 'com.google.guava:guava:11.0.2'
    compile files ('libs/gcm.jar')
}

The compile directive is similar to mavens compile scope in that the dependency will be bundled into your packaged .apk.

Gradle also supports Android library projects. The “New Build System” compiles library projects into .aar packages, which can be consumed by the main project. The main advantage of the .aar format is its ability to handle dynamic Android resource ids. You will be able to ship an *.aar archive and consume it in your main project without having to create all of its ids during compile time of the main project.

Library projects have to be listed in a settings.gradle file and all projects taking part in the build can reference any other project listed in that file.

Where the gradle build has its real strength is in creating multiple versions of the same app. For example, a free and a paid version, or different versions for various cpu architectures. I won’t go into detail but you should read all about it here.

Shortcomings

Now that we have discussed some of the strengths of the gradle build system, lets discuss some of the pitfalls:

The gradle build is not yet able to deal with the most common dependency format for library projects: the maven apklib. Currently you can only consume maven artifacts that are packaged as jars. This rules out a lot of high profile dependencies such as the actionbarsherlock or the viewpagerindicator. If you want to depend on these resources you will have to keep a source reference in your project (or package them as an .aar).

The gradle build system offers good support for instrumentation tests you run on your device, but it is currently very hard to run standalone robolectric tests. The main problem is that robolectric does not understand the gradle dependencies so that it cannot gather sub-dependencies, and so on.

Support for the Android Development Tools (ADT) is currently non-existent although this is very likely to change with future releases. The ADT cannot deal with the default folder layout by gradle, nor can it deal with declared dependencies. Therefore, you have to maintain two build infrastructures: one for Eclipse (project.properties etc) and one for the gradle build.

Wrap Up

The “New Build System” build sounds awesome! As long as it can deliver on all its promises. At the moment, I can not recommend it for larger projects due to the lack of robolectric support and problems with maven dependencies. I have discussed the issues raised here with +Xavier Ducrohet, the lead architect of the build system, and he assured me that most of the issues will be addressed. At the Droidcon Berlin I spoke to Hans Dockter, the CEO of Gradleware and co-architect of the “New Build System”, and once gradle becomes the driving engine for the ADT the entire toolchain should be covered. If the Android library ecosystem were to adapt gradle, it would have a very bright future.

4 Comments. Tagged with android, build, Gradle, android, build, Gradle

Bill Lahti: Link to useful Android resources

blahti — 2013-05-01T11:07:28+00:00

I found a link on Google+ to a very useful blog post. It's called "Resources every Android developer must know". The author is Sergey Povzner.

Gabor Paller: Advantages and limitations of PhoneGap for sensor processing

Gabor Paller — 2013-04-28T19:58:00+00:00

This is my Droidcon Tunis 2013 presentation about the effect of the web application model on battery consumption.

Test programs related to the slideset are available here. You have to be logged into Sfonge website to access those.

Lars Vogel: Android – Why not to use static for View fields in your Activity or Fragments by Lars Vogel

Lars Vogel — 2013-03-12T10:13:22+00:00

Your should not use static for defining fields for Views in your Android application.

Then creating a View, the LayoutInflater (used in setContentView(R.layout.ID)) uses the current Context (of the Activity) and pass it to the inflated Views. A reference to the given Context is always kept by the View class and can be retrieved via the getContext() method.

As a consequence, keeping a static reference on a View means that your Activity keeps a reference on your View which keeps a reference on the activity instance. This is what leads to the leak.

Thanks to Cyril Mottier for explaining that in G+.

Gabor Paller: Data capture application for car speed, accelerometer, compass and gyro fusion experiments

Gabor Paller — 2013-03-10T18:41:00+00:00

In my previous post I wrote about my enthusiasm of integrating car sensors with the mobile device's own sensors. The first step was to implement a data capture application that saves sensor data into a file. This time I decided to save the gyro, accelerometer and compass sensor data from the phone and the speed as measured by the car's speedometer. The most interesting aspect here is how we obtain the speed data.

There are two levels of interfaces playing role here. OBD2 interface and the protocols accessible over it is the first level offered by the car's on-board electronics. This interface is not trivial to talk to but fortunately all the complexity of OBD2-related protocols is implemented by the super-popular ELM327 microcontroller from ELM Electronics (or its compatible copies). On one side the ELM327 chip talks to the car's ECU using the OBD2 interface. On the other side, it offers a modem-like serial interface. Popular connection option is USB but for our Android client, Bluetooth is a better option. ELM327-compatible adapters are available at a low cost, for example I bought the very basic version below.

ELM327 has a very simple, yet powerful interface. In the first phase the chip is set up by issuing a series of AT commands reminiscent of the Hayes modem commands. The best place for reference is the ELM327 specification. The most important command is the ATS0 command. This instructs the chip to auto-detect the protocol used on the OBD2 interface. Once this auto-detection is successful, the car sensors can be queried by sending the PID code of the sensor in question. For example for the car's speed one sends:

010D

The ELM327 chip then talks to the car's ECU, obtains the sensor data and returns a response like this:

410D0C

Where "4" is the ID for response, 10D is the PID of the sensor and 0C is the value. Some OBD2 PIDs have complex coding but fortunately for the speed sensor 0C simply means 12 km/h.

Click here to download the example program.

Before you start using this test application, make the Bluetooth pairing of your device with the sensor from the Android Bluetooth settings. Either you can use the real thing (ELM327 interface connected to a real car) or you can use Ryan C. Gordon's great OBDSim application that can run on a Linux box and can simulate a Bluetooth-connected ELM327. In theory, OBDSim can also run on Windows, I tested only on Linux. Setting it up is not trivial but it saves a great deal of time if you develop for the ELM327 interface.

Then you can start the test application. First connect to your ELM327 device from the menu ("Connect a device - secure"). If the connection works properly, you should see a series of AT commands and responses flashing on the screen then the speed appears (e.g. 0 km/h if you do it on a real car). This time you can start the sampling ("Sampling" check box) and the application will save all the sensor information into a file in the SDCARD in CSV format. The name of the file is gyrocarcapture_<date>.csv and its format is very simple. One warning here: sadly the timestamp format used for the speed sensor and the device's own sensor are different: the sensor timestamps are coming from the SensorEvent object and the time stamp for the speed data comes from System.currentTimeMillis(). As device sensor events are very frequent, I use the last device sensor timestamp for the speed sensor too when processing these files. The speed sensor sampling frequency is approximately 1 Hz.

The application can be extended easily to sample other car sensors too. However, in its present form it is good enough to detect if the driver slows down in front of a speed bump (accelerometer-car speed sensor fusion).

Or to figure whether the driver takes the bend too quickly (gyroscope-car speed sensor fusion).

Lars Vogel: Determine the active Android framework maintainer by Lars Vogel

Lars Vogel — 2013-03-05T09:53:23+00:00

If you want to know the current Android maintainer you can use the following link:

Android framework maintainer

Thanks to Arvid Gerstmann for pointing me to that URL on Google+.

Ed Burnette: So long, fellow travelers

2013-02-16T05:32:05+00:00

Seven years writing at ZDNet, and all I got was this stupid T-Shirt.

Ed Burnette: iOS 6.1 banned from corporate servers due to Exchange snafu (Updated)

2013-02-09T00:41:07+00:00

iPads and iPhones running the newest version of iOS are being blocked in some enterprises because bugs are overloading corporate Exchange servers.

Androidsx: Technical Debt In Android App Development

Pablo Pera Mira — 2013-01-07T16:06:21+00:00

Many indie developers think they can get away with introducing hacks all over the place while developing an Android application. Those shortcuts do speed up development. Probably, they’ll even take you closer to the launch day. However, chances are that they’ll end up doing more harm than good. The main reason is pure technical debt. [...]

Androidsx: Our progress in Android development in 2011: Part 1

Pablo Pera Mira — 2012-04-25T20:01:32+00:00

Let us share what we did in 2011 in the Android development field. Not that it is extraordinary in any way, but it may be interesting for some folks out there working on side projects, for you to see an example of what you can get done in a year of evenings and weekends. We’ll [...]

AndroidBytes: Difference Between Android 2.3.3 and Android 2.3.4

admin — 2011-09-11T10:33:38+00:00

The post title is referring to the difference between Android 2.3.3 and Android 2.3.4 because it’s just one visible difference: Support voice and video chat using Google Talk. Of course, there are lot’s of bug fixes, but these are in any release.

So, Android 2.3.4, the latest over the air Android version update brings an exciting new feature to Android based devices. With the upgrade to Android 2.3.4 you can video or voice chat using Google Talk. Once updated you will notice a voice/video chat button next to your contact in Google Talk contact list. With one touch you can send an invitation to start a voice/video chat. You can make video calls via 3G/4G network or via Wi-Fi. The Android 2.3.4 update in addition to this new feature also include some bug fixes.

AndroidBytes: HTC Sense 3.5 is coming to HTC Desire

admin — 2011-09-09T17:26:45+00:00

coolexe, a very appreciated developer from xda-developers has managed to port HTC Bliss (3.5) to HTC Desire (and HTC Desire HD) in a custom ROM based on Android 2.3.4. From the feedback received, there some lag in the app drawer, there are some problems with BT, Video Recording, HTC Wall, LockScreen, Skin preview, FM Radio, but hey.. it’s the first release and the fixes will surely come… and it’s the best port released, so I think it worth a try. I’ll try to review it as soon I’m able to install it on my phone, but until then, here are some features and some screenshots:

Features:

Leaked Android 2.3.4 with Sense 3.5 For HTC VivoS WVGA Screen
Cache Partition Mount as Re-writable *Now u can save ur data on cache partition too*
Andrev_oc Demon with Daemon Controller v2.11.apk
Screen state scaling Customizable…
……………….screen on - ondemand 254-1152 MHz.
……………….screen off - conservative 254-384.0 MHz.
RAM Tweaks
Speed tweaks with Smoothness patch
Rom Optimized for Speed & Stability
Busybox 1.19.0, Root, Superuser
Automatic ZipAlign by Wes Garner, slightly adjusted by ROBO
Updated APNs to Cyanogens big list (over 1300 providers)
All HTC Themes, Widgets & Addons
Host file symlink to data partition for easier update
Customizable Bootanimation and downanimation
Some Hidden bloat-ware removed
AND MUCH MORE.
Languages supported: wwe

Screenshots:

Download: Just go to his thread in order to download it because you can find some other goodies too

If you manage to install it, please leave your opinion here

Planet Android

Android Apps: Say Hello to My Little Friend : Huawei Ascend P6 Goes Live

XDA Developers: Forum Added for the Samsung Galaxy Mega

Android Apps: Samsung To Launch First Tizen Smartphone Based on Exynos 4

DroidGamers: Like the Where's My series from Disney? Mickey will be joining the crew shortly

AndroidPIT: HTC Desire 200 is here: Lower end device with high aspirations

DroidGamers: Phosphor Games drops the price of World War Z down to $0.99 for a limited time

AndroidPIT: Sony Xperia Z gets the Yankee Treatment

LandOfDroid: My Little OPPO Rant

XDA Developers: Voice Control Your Phone with Tasker and AutoVoice – XDA Developer TV

Swarm: Try Your Skills And Reflexes With Paddle Master

Android-Games: Shoot A Ray releases Pulse Infiltrator for Android

LandOfDroid: The Quest for Addtional Power -v- Reduced Functionality

Coderz Heaven: We are Moving………

More Similar Posts

Mutual Mobile: Weekly Mobile News Roundup: June 17

News and Insights

Apple Debuts iOS 7, OS X Mavericks, and New Macs: Everything You Need to Know – The Verge

Cook Unveils Mission Statement, iOS 7 Gets Colorful, New iPhone – Forbes

How Apple’s iOS 7 Changes Everything For App Designers – ReadWrite

Why iOS 7 Looks Unfinished (Spoiler: It’s Because It’s Unfinished) – TIME

Why Do Super-Elite Customers Get All The Attention? – Forbes

With Wearable Tech, Human Behavior is Now a Design Problem – GigaOM

Saks Deploys 2,000 iPads in Stores, to Launch OFF 5th Website in Fall – RIS

Mobile Marketing Isn’t About Screens or Devices, It’s About Behavior – AdAge

Research

[Infographic] Mobile at WWDC – The Push

A Day in the Life of a Mobile Consumer – Flurry

82% of eCommerce Merchants Not Tracking Mobile Sales – Mobile Commerce Daily

One-Third of Americans Now Own Tablet Computers – New York Times

Smart Mobile Devices Account for Small Share of TV Viewing – eMarketer

Mark Murphy: Calling for More Android Developer Support Sites

Android UI Patterns: Dont's of Android design

Re-skinning everything

2.3 / iOS style tabs

Non-standard action bar

Rounded text containers, boxed text fields and list carets

Quick actions replacing content

Apps that feel like a website

Galaxy Tab Review: Galaxy Tab 8.9: Download Android 4.2.2 CM10.1

Mutual Mobile: Mobile Minute: June 13

Chet Haase: DevBytes: Animating ListView Deletion

Android-Games: The Official Man of Steel game Soars onto Google Play

Swarm: Swipe Your Way With Swipebox

Coderz Heaven: Use of custom animations in a FragmentTransaction when pushing and popping a stack. or How to apply animations in Fragments when pushing on to a stack?

More Similar Posts

Google And Blog: Is Your Cell Phone Private When Others are Involved?

Android UI Patterns: Google's first pull-to-refresh - a good first try

Should you change your refresh button to this?

Twitter's pull-to-refresh vs. Google's pull-to-refresh

Mark Murphy: The Busy Coder's Guide to Android Development Version 4.9 Released

EuroDroid: BBC Weather app hits Android

Related Posts

Chet Haase: DevBytes: Custom Activity Animations

Google And Blog: Android Stock Keyboard Now Available in Google Play

SlideME: Streamline Your Application Distribution with SlideME’s AppDF Support

Hello Android: Insights from Google I/O 2013: How to Make Money from Android App Development

Android Developers: Google Play Developer 8-Step Checkup

1. Boost your developer account security

2. Protect your keystore

3. Check your email addresses

4. Familiarize yourself with the policies

5. Set up team processes

6. Configure your Developer Console UI languages

7. Refresh your app’s marketing materials

8. Stay on top of developer news

Hello Android: Google Play downloads look to overtake Apple by this fall

Android Developers: Bootstrap Your App's Cloud Services with Mobile Backend Starter

Mobile Backend Starter

Quick setup and integration

See Mobile Backend Starter in action at Google I/O

Luke Meyer: Android and openness

Luke Meyer: Is this thing on? ::feedback:: ouch…

Marakana: Android Enterprise Security at AnDevCon

Marakana: Android Security Underpinnings at AnDevCon

Romain Guy: Android sessions at Google I/O 2013

Romain Guy: Launcher

EuroDroid: STATS: Android powers 58.4% of UK smartphone sales in 2013

Related Posts

Cyril Mottier: Pushing the ActionBar to the next level