Well, the long wait for the new firmware update to owners of the Samsung Galaxy S3 and Note 2 might be coming to an end soon. An update to Android 4.2.2 is slated to be coming in the third quarter of 2013 according to a new insider source, so we can hopefully expect an update to these devices sometime between July and September.
The Galaxy S3, along with the Note 2, might see an update to Adnroid 4.2.2 by as early as July. / © SamMobile(This is a preview - click here to read the entire entry.)
With the official announcement of the Ascend P6 yesterday in London; Huawei is hoping to jump into the ring of high-end smartphones with the release of their ultra slim design. Whether or not the Chinese company can compete in the race for the top Android phone, alongside the HTC One, Sony Xperia Z, and Samsung Galaxy S4 still remains to be unclear. However, let’s have a look at all the devices side by side.
So, how does the Ascend P6 stack up compard to the rest? / © AndroidPIT(This is a preview - click here to read the entire entry.)
On May 29th, Mutual Mobile and the Sales Management Association hosted a free and informative webinar about making your salesforce leaner and meaner through mobile technology. Luckily for you, we recorded it.
Sam is the master and commander of Mutual Mobile’s marketing efforts. He’s been in the war room for every mobile sales tool that’s passed through our doors, and he knows what it takes to infiltrate every territory from the automobile industry to the education system.
Mike Nowlin is a four-star general of mobile sales enablement. He carefully studies target markets until it’s time for our highly-trained designers and engineers to safely move in on your competition while their defenses are down.
Access the video here.
The post Operation Sales: how to arm your team with tablets appeared first on Mutual Mobile.
Icons are some of the most commonly themed elements of the Android UI, and there is certainly no shortage of great looking icon packs available for download. The downside, however, is that some of these packs are designed to be used with specific launchers. And if you are anything like I am, quite attached to your launcher of choice and unwilling to switch, this can be frustrating. While there are ways of making use of any icons on any launcher, they can often be tedious if the compatibility isn’t there to begin with. With a little help from the Xposed Framework though, that process can be simplified considerably.
XDA Senior Member ruqqq developed Icon Themer, an Xposed module that allows you to use icon packs designed for specific launchers on a variety of other popular launchers quickly and easily. The module also offers a more consistent theming experience than other methods, as the icons are applied system-wide instead of simply on your home screen. The mod supports both paid and free icon packs available via the Play Store, and it will work on both odexed and deodexed ROMs. You need to be running Android 4.0+ with root access and of course have the Xposed Framework installed. After that, you can simply download the icon pack of your choice and apply it through Icon Themer.
Check out the modification thread for more information.
It’s frustrating to see slick new features that you can’t use when supporting devices with older versions of Android. Sometimes Android adds in support for a few previous versions, like when the ActionBar was added. But other times, you’re just going to have to do it yourself. That’s what XDA Senior Member icechen1 did to make the slick looking TimePicker from Android 4.2 work with devices as old as 2.1 (Eclair).
He’s calling it MicrowaveTimePicker, which is a great descriptor. These screenshots show that the button layout and time display is exactly what you’d expect to see on the control panel of a microwave oven. That familiar look is what great interfaces are made of, as most users will immediately feel at home typing in the the time setting.
The library is available from his GitHub repository. The readme file documents how easy it is to start using it. Add the Class as an item in your preference menu xml, and it’ll launch like an Activity. There is also the option of displaying the interface programmatically as a dialog.
You can find links to other 4.2-like pickers in the comments of the Reddit thread. Icechen1 many have duplicated some work by building up his own library, but it can’t hurt for the rest of us to have several to choose from.
Ubisoft's companion app for their Watch Dogs game has essentially been turned into a game itself. Technically this is more of a game than an app although it really is a bit of both. Regardless of what exactly this application now is, Watch Dogs Live has undergone a soft launch in Canada to do some final testing before it launches worldwide. When that happens, if you're at the top of the leaderboard when the game end, you'll win a car.
This isn't an in-game car either but an actual Watch Dogs branded Scion. The game itself is a location-based hacking game where you'll be able to unlock certain data when you visit locations in real-life. Of course these are specific locations and hitting up your local 7-11 won't do. When you get to a location, you hack it and control it. This earns you in-game cash which you can then use to upgrade your hacking skills.
So how do you get on the top spot of the leaderboard? Well the 'score' is determined by how much data you've unlocked. If you've unlocked the most data by the time the game ends, you'll be in the #1 spot and net yourself a new car. While working your way to the top, there will be weekly challenges as well with other real-life prizes up for grabs as well. If that isn't enough for you, there will be real-time monthly missions where you can play with other gamers to further the cause of the game's hacking faction Deadsec.
So when will the craziness begin? There is no exact release date for the worldwide launch but considering the game is already out in Canada on iOS, it shouldn't be too much longer for the worldwide release which will happen on both Android and iOS.
Website Referenced: PocketGamer
Talisman Prologue HD is a board game that has been around for quite a long time. This game is also available for iOS devices. I never played this game before but after trying the electronic version, I think I would have liked the board game.
Name: Talisman Prologue HD | Developer: Thumbstar Games | Category: Brain & Puzzle | Players: 1 | Version: 1.0.6114 | Size: 48 MB | Price: $4.99 |
Before I get into the specifics of the game, some details:
- Single player game
- No profiles or the ability to save games
- Game lengths vary
- 10 different characters
- 50 quests to play
- Multiplayer game is scheduled for release Autumn 2013
This is from the developer regarding the game's ruleset:
While Talisman Prologue HD uses the rules of the board game, there are some differences in the gameplay. The biggest new addition to the game is the introduction of quests. In the classic board game of Talisman, the goal is to reach the Crown of Command and claim it. In order to provide a varied, rich, and story-focused experience each time you play Talisman Prologue HD, you play one of fifty unique quests for each of its ten characters. The quests have goals that the player must complete in order to lead his hero to victory.
This is a fun game and pretty easy to play. There is a help section and some background info on the game. When you first start, there is a tutorial to walk you through the basics. You start the game off as a warrior. Once you finish that warrior training you will unlock the troll, once you finish that training then you will unlock another character and so on.
Each character has strength, craft, fate, gold, and lives plus his bent (good, evil, neutral) all of which will influence how the game is played out. For each character there are 5 missions and your goal is to finish them in a few rolls as possible.
To play, you roll the dice and move your character around the board. You do not have to move in a single direction like Monopoly-you can go any way to want. The board will highlight on your possibly moves. When you land on a space you will do want it says, which usually is drawing a card or two. Once you finish doing what the cards say you roll again. One neat thing about this game is that no two games are the same.
As was mentioned above, each game will vary in length, just depends on where you go on the board (via your dice roll) and how fast you can complete the quest requirements. I do not mind this, but the one thing I do not like about the game is the inability to save games (quests) in progress. Not sure why the developers chose to do this-even with a board game you can get up from it for a while and come back.
Despite that one issue, this is a really fun game. The graphics, the virtual board, game pieces, music, and overall game play make this a keeper. This reminds me a lot of the board games like D&D that I played as a kid.
Play Store Link
There probably isn’t a better superlative to describe this free service provided to all Google Plus users. Auto Awesome actually consists of a few edits that Google+ will make to your photos under the right circumstances.
The Auto Awesome features are as follows: (https://support.google.com/plus/answer/3113884?hl=en)
HDR, or High Dynamic Range, is the process of taking multiple exposures of the same image. By merging these images together, your photos will achieve a greater range of shadows and light. Uploading three similar images at different exposures–low, medium, and high exposure–will create an HDR image for you through Auto Awesome.
If you’ve taken a series of photos in succession (at least 5), Auto Awesome will stitch these photos together into a repeating short animation.
If you’ve taken a few group photos, Auto Awesome will choose the best shots of each person in your image and merge them into one great looking photo.
If you’ve taken a series of photos with overlapping landscape views, Auto Awesome will stitch these photos together into a panoramic image.
If you’ve taken a series of portraits sharing similar background elements, Auto Awesome will compile these photos together into a photobooth style grid. Mix is meant to showcase portrait photos taken with similar backgrounds in time, so it works best when there are close-ups of faces.
The features are really incredible when you consider that it happens automatically on Google’s servers. All you have to do is turn on Auto Upload on Google plus and start taking pictures. This is great for phones that don’t have great cameras or people who like to take good pictures but hate to edit them. You’ll receive a notification when your photos have finished uploading and/or there is a new Auto Awesome photo created by Google.
Don’t worry, all of your photos are private until you decide to share them with people. Even if you have auto upload turned on.
Last but certainly not least, Google Plus will automatically enhance every photo you take with a wonderful mix of color correction and contrast balancing. The results are really quite impressive.
On June 25th, you’ll get a rare chance to learn about the true potential of Google Glass and other wearables at a free webinar conducted by industry experts.
Sarah Rotman Epps – Senior Analyst, Forrester
As a Forrester Senior Analyst serving marketing leadership professionals, Sarah studies the evolution of personal computing: how devices are changing, the new consumer behaviors they produce and the industries they disrupt.
Sam Gaddis – Chief Marketing Officer, Mutual Mobile
Being Mutual Mobile’s Chief Marketing Officer has given Sam a keen understanding of where mobile works and, more importantly, where it often doesn’t. He’s guided go-to-market strategy for dozens of Fortune 500 brands.
Tuesday, June 25, 2013
10:00am CT – 11:00am CT
Register online to attend this free webinar.
The post Start exploring Google Glass appeared first on Mutual Mobile.
Two days ago those of us who backed the Minuum Keyboard on Kickstarter received an email stating it would be released as a beta as of yesterday June 18. At least that’s what I and most people thought. By mid-day it was clear that few people had received their invite. It also looks like the Minuum team (smartly) chose to make sure important reviewers or influential backers received the beta first. By noon you were already seeing people asking why they hadn’t received their beta invite yet….
At 6:27 Pm on June 19 The Minum Team Sent out a message on Google Plus:
Hi everyone!
We’ve been gradually rolling out beta invites to all of our supporters today, but have been held back by some challenges with the Google groups beta platform — if you’re a supporter and haven’t yet received your invite, thanks for waiting, and we’re working as hard as we can to get this to you within the day!
Meanwhile, you can check out our new Minuum how-to video here: How the Minuum keyboard works
Will & the Minuum team
In my opinion 6 PM on the “launch day” is way to late. By 3 O’clock I was already scouring the internet for a downloadable APK. I wasn’t the only one. There were several backers online who were obviously patient at first. I even saw someone comment that the posting of an APK would be a “dick move.” Forgive me, but I place the blame completely with the minuum team and here’s why.
1. Your inability to create a contingency plan allowing backers to verify their data and manually download the apk is inexcusable. The Swype Keyboard team did a beta like this for about two years…Its not like the Minuum team didn’t have a model for success they could follow.
2. Unless you never used the new Play Store Beta distribution before you’re launch (That can’t be it right??? Why advertise the Alpha test of your Beta release then?) you should have seen this issue coming.
3. The people who know about and actively seek out your beta are probably tech savvy. They were going to share that apk with the understanding that the more data a beta program can obtain the better.
Unfortunately the user who decides to share an application he/she paid for is not herself required to verify that the person they share it with is a backer. Some people who actually paid their $5 on kickstarter might be upset that non-backers now have access to something they paid for. Which brings me to…..
4. No Play store verification.
It is 9:53 am on June 19th and I have not received my beta invite. So…this morning I downloaded the apk from an individual who was kind enough to host a link. I installed it on my S4 and Nexus7 and was up and running with no problems. If the Play store Beta was so important that I should still be waiting for an invite….you probably should have included a way to verify who was using your app.
Update: Received my invite at 9:52 AM Eastern Time. Better late than never I suppose.
When T-Mobile overhauled its plans a few months ago, I felt a little excitement. At a time when the big players are getting more and more restrictive with contract terms and upgrades, T-Mobile made a turn in the completely opposite direction. Their plans don’t reflect contract subsidies, and you pay extra per month only when you’re actively paying off your phone. If I weren’t stuck in a contract myself I’d probably consider switching.
Apparently T-Mobile was onto something, because one of their major competitors, AT&T, has created a similar plan. It is under the prepaid GoPhone umbrella, but it offers far more features than AT&T has made available in the past. The biggest change: the addition of LTE. That puts GoPhone on similar ground to T-Mobile’s service, though T-Mobile still primarily uses HSPA+.
With T-Mobile you get unlimited talk and text, plus 2.5GB of data, for $60 per month. With AT&T GoPhone you get 2GB of data with that same unlimited talk and text for the same $60 per month. True, T-Mobile gives you 500MB more data, but AT&T gives you a wider network. With both services you can bring your own phone, putting them on even leveler ground.
The difference comes if you want more data. AT&T has a very reasonable rate of $10 per GB extra per month — reasonable for prepaid, at least. T-Mobile, on the other hand, bumps you to unlimited smartphone data for that $10 per month. It’s unlikely AT&T ever goes in this direction; they actually did offer unlimited prepaid data for $20 per month, but put an end to that plan more than four years ago.
So while T-Mobile has better options, AT&T did just create a competitor with its prepaid brand. It’ll be interesting to see which customers feel the AT&T offering is better.
The post Is AT&T’s New GoPhone Plan Better than T-Mobile? appeared first on MobileMoo.
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…
Hello all……
We are moving on to a faster server… So if you experience any difficulties please bear with us and inform us.
Thankyou
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!
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.by Juhani Lehtimäki (noreply@blogger.com) at June 17, 2013 09:01 AM
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.
by Chet Haase (noreply@blogger.com) at June 14, 2013 09:06 PM
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.
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.
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.
by Juhani Lehtimäki (noreply@blogger.com) at June 10, 2013 10:03 PM
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.
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.
by Chet Haase (noreply@blogger.com) at June 07, 2013 04:28 PM
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.
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.
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.
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.
As a developer, you are responsible for checking two important email addresses:
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.
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.
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.
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.
by Android Developers (noreply@blogger.com) at June 06, 2013 09:21 PM
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.
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 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:
You can set up and run the Mobile Backend Starter in just few steps:
Consts.java file and set the PROJECT_ID to the Project ID of the project you created in the Google Cloud Console. 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.
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.
by Android Developers (noreply@blogger.com) at June 03, 2013 05:14 PM
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?
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!
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:
In addition you can download the slide for the Android Graphics Performance talk:
And the slides for A Moving Experience:
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!
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.
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.
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.
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
Pretty logically, the style of the ActionBar is defined in values/styles.xml as follows:
1 2 3 4 5 6 7 8 9 10 | |
Finally, we can use these themes in order to style our Activity.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | |
Note that by using themes/styles we remove all potential flickering issues at startup (see Android App Launching Made Gorgeous for more information).
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | |
Then, we can use this new scrolling container in an XML layout:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
1 2 3 | |
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.
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:
1 2 3 4 5 6 7 8 9 10 11 12 | |
The gradient is overlaid using a wrapping FrameLayout:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
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 disturbing1. A simple way to do that is to modify the NotifyingScrollView to force the maximum over scroll values to zero when necessary:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | |
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.
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 20131. 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.
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 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.
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.
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).
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
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 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 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!
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.
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().
by Stripeymilk (noreply@blogger.com) at June 20, 2011 03:42 AM
by Stripeymilk (noreply@blogger.com) at June 20, 2011 04:13 AM
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.
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
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)
{
}
}
}
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:
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!
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
V
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
by NeatPIX Team (noreply@blogger.com) at January 30, 2010 10:28 AM
by NeatPIX Team (noreply@blogger.com) at January 26, 2010 01:29 AM
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.
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.”
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.
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 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.
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!
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:
This process uses three separate AsyncTask instances:
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:
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.
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.
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" />
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.
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!
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
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?
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 three source posts are:
Both the posts and the comments were very helpful, but somewhat out of date now. How to put it all together?
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.
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.
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 the zipped source code that I’ve gathered for each platform you are developing for.
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!
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
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!
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.
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.
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 Post Google I/O: The State of Android Development [UPDATED]](http://developer.android.com/images/tools/android-studio.png "Post Google I/O: The State of Android Development [UPDATED]")
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.
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)
![as resource Post Google I/O: The State of Android Development [UPDATED]](http://eclipsesource.com/blogs/wp-content/uploads/2013/05/as_resource.png "Post Google I/O: The State of Android Development [UPDATED]")
Implementation folding (Similar to Lambda expression in Java 8)
![as code folding Post Google I/O: The State of Android Development [UPDATED]](http://eclipsesource.com/blogs/wp-content/uploads/2013/05/as_code_folding.png "Post Google I/O: The State of Android Development [UPDATED]")
Parameter prediction (Correct constants are proposed for int parameter)
![as prediction1 Post Google I/O: The State of Android Development [UPDATED]](http://eclipsesource.com/blogs/wp-content/uploads/2013/05/as_prediction1.png "Post Google I/O: The State of Android Development [UPDATED]")
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.
![broken android Post Google I/O: The State of Android Development [UPDATED]](http://eclipsesource.com/blogs/wp-content/uploads/2013/05/broken-android.jpg "Post Google I/O: The State of Android Development [UPDATED]")
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).
![gardle android Post Google I/O: The State of Android Development [UPDATED]](http://eclipsesource.com/blogs/wp-content/uploads/2013/05/gardle-android.png "Post Google I/O: The State of Android Development [UPDATED]")
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.
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.
![android aar1 Post Google I/O: The State of Android Development [UPDATED]](http://eclipsesource.com/blogs/wp-content/uploads/2013/05/android-aar1.png "Post Google I/O: The State of Android Development [UPDATED]")
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.
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.
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.
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.
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.
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?
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.
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.
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.
by Gabor Paller (noreply@blogger.com) at April 28, 2013 07:58 PM
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+.
by Gabor Paller (noreply@blogger.com) at March 10, 2013 06:41 PM
If you want to know the current Android maintainer you can use the following link:
Thanks to Arvid Gerstmann for pointing me to that URL on Google+.
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.
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:
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
Abduction!
Amazon Wireless
Android Apps
Android Developers
Android Games
Android Magic
Android UI Patterns
Android from Scratch
Android-Games
AndroidBytes
AndroidPIT
AndroidTip Guys
Androidsx
Androitism
Bain Labs
Bill Lahti
Blue Scream
Bolting Android Apps Together
Brain Flush
Chet Haase
Chris Boyle
Cyril Mottier
David Welton
Droid Sector
DroidDevelop Stream
DroidGamers
Eclipse Source
Ed Burnette
Ed Burnette
EuroDroid
Everything and Anything Android
Gabor Paller
Galaxy Tab Review
Galaxy Tabs
Google And Blog
Gushiku Studios
Hakan Tandogan
Hello Android
James Elsey
Jason Wei
Kenneth Lewelling
LandOfDroid
Lars Vogel
Luke Meyer
Marakana
Mark Murphy
Mart Roosmaa
Mutual Mobile
NeatPIX
Nikhil Gupta
Notion Ink
PewPew dev blog
Romain Guy
Sean Catlin
Skyler Slade
SlideME
Stripeymilk
Swarm
The Powerbase
Ugo Sangiorgi
Volker Leck
XDA Developers
