If you submit your app to iTunes Connect and shortly afterwards you get back an email from the iTunes store stating that your app has the problem of an invalid signature, here is a possible solution for this problem.
The screenshot below might help you:
The standard way on Android to get a thumbnail is to use MediaStore.Images.Thumbnails.getThumbnail or MediaStore.Video.Thumbnails.getThumbnail dependent if you want a thumbnail from an image or an video. Both of these methods return a Bitmap ready to use.
However, sometimes you may want to have the path to the thumbnail, e.g. because your own ContentProvider also need to provide thumbnails for files. The documentation of the thumbnail functionality is not that clear currently, but to build this functionality you can query the standard thumbnail content provider similiar to querying the media store for the real file.
To get the path of a mini thumbnail (MINI_KIND) for the image on the external storage you could do the following:
String getThumbnailPathForLocalFile(long fileId)
{
Cursor thumbCursor = null;
try
{
thumbCursor = getContext().getContentResolver().
query(MediaStore.Images.Thumbnails.EXTERNAL_CONTENT_URI
, null
, MediaStore.Images.Thumbnails.IMAGE_ID + " = " + fileId+ " AND "
+ MediaStore.Images.Thumbnails.KIND + " = "
+ MediaStore.Images.Thumbnails.MINI_KIND , null, null);
if(thumbCursor.moveToFirst())
{
// the path is stored in the DATA column
int dataIndex = thumbCursor.getColumnIndexOrThrow( MediaStore.MediaColumns.DATA );
String thumbnailPath = thumbCursor.getString(dataIndex);
return thumbnailPath;
}
}
finally
{
if(thumbCursor != null)
{
thumbCursor.close();
}
}
return null;
}
Things to consider:
One of the biggest challenges for me is often where to get good graphics and sound resources. There are already a lot of lists from other developers available, but still my own list might be useful for you, too. 
Since I finally found the opportunity to have a look at some Google IO 2011 sessions, here are some links to sessions I can recommend:
Android Development Tools:
Shows some neat tips & tricks for using new (and old) features of the ADT plugin for Eclipse
Android Protips: Advanced Topics for Expert Android App Developers
Provides a lot of great tips and some patterns for common problems, e.g. keeping backward compatibility while still using new features, doing battery efficient data updates, etc.
Memory management for Android Apps
Background information about the garbage collector, memory management in the Dalvik VM and how to find memory problems by using the Eclipse Memory Analyzer
Building Aggressively Compatible Android Games
A good high-level summary of how to make apps compatible for many devices.
If you have asked yourself how to can return a handle to a temporary file from an own Android ContentProvider implementation, here is a good solution I found at tomgibara.com by utilizing the behavior of the underlying linux file system:
The basic scenario is this: You have implemented a ContentProvider and you want to use it to return something that is too big to fit into a cursor, say an image. It’s clear from the relevant Android platform javadocs, though perhaps not from the general ContentProvider documentation, that this is done by implementing openFile and returning a ParcelFileDescriptor.
But now suppose that the image resource is being rendered on the fly. How do you implement openFile?
As per the contact of openFile you need to return a ParceFileDescriptor which means that the resource must be returned via an open file (or possibly a socket, which we’ll ignore). This means that the image must first be written to a file, which is then opened as a ParceFileDescriptor. The interesting question here is when do you delete the file?
You can’t wait until the calling process has finished reading the file because (a) you won’t get notified when that occurs and (b) it may never exhaust the stream anyway. You can’t rely on the calling process to delete the file for you either, also, the whole idea behind wrapping the resource in this way is to guard it from direct access by other processes. You could delete the file after a fixed time period — assuming that the caller will have finished reading the file by that time. But this is unnecessarily complex, because the answer turns out to be very simple:
You delete the file immediately after you’ve opened the ParcelFileDescriptor but before you return it from the openFile method.
…
The reason this works is down to the way that Linux filesystems operate: directories maintain links to files, when a process opens a file a new link is created, closing a file or removing it from a directory removes a link. When there are no links to a file, the file is deleted.
So by opening the file in our application, we create a link to it. Then ‘deleting’ the file actually unlinks it, but the file won’t really be deleted until the file descriptor is discarded (ie. the last link is removed). This will happen automatically at some point after the calling application has finished accessing the file and any associated
ParcelFileDescriptorobjects have become garbage.
Read the full post at Returning dynamically generated resources – Parentheticals & Excursions.
Coding the Architecture provides a very nice slide set giving a very good high level overview of why and how to document your software architecture in a practical way. As I wrote, it is a slide set and therefore only provides very short summaries on the different aspects. Nevertheless, it provides some good suggestions which topics should be covered and how to document them.
Key takeaways:
You can find the slide set here.
BTW: Coding the Architecture contains a lot of useful resources for software architects.
In this truly unique technical book, today’s leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects — including Neal Ford, Michael Nygard, and Bill de h ra — offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from years of experience. Among the 97 principles in this book, you’ll find useful advice such as:
- Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar)
- Chances Are, Your Biggest Problem Isn’t Technical (Mark Ramm)
- Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
- Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
- For the End User, the Interface Is the System (Vinayak Hegde)
- It’s Never Too Early to Think About Performance (Rebecca Parsons)
To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project.
You can find the 97 things for free here.
Google announced on its Android Developers Blog that they are now providing a device dashboard showing the distribution of the Android version accessing the Android Market (later on also including hardware characteristics of devices).
As a developer, I often wonder which Android platforms my applications should support,especially as the number of Android-powered devices grows. Should my application only focus on the latest version of the platform or should it support older ones as well?
To help with this kind of decision, I am excited to announce the new device dashboard. It provides information about deployed Android-powered devices that is helpful to developers as they build and update their apps. The dashboard provides the relative distribution of Android platform versions on devices running Android Market.
…
In summary, Android 1.5, 1.6, and 2.0.1 are the 3 versions of the platform that are deployed in volume. Our goal is to provide you with the tools and information to make it easy for you to target specific versions of the platform or all the versions that are deployed in volume.
We plan to update the dashboard regularly to reflect deployment of new Android platforms. We also plan to expand the dashboard to include other information like devices per screen size and so on.
Don’t get me wrong: the data is very interesting. However, it strongly reminds me on the situation on Windows, where still about 30% of the users use Windows XP. Having such a big fragmentation of OS versions really forces you to either make big compromises and build your application only using the features of the lowest OS version or to make your application adapt to the OS version it is running on. The later one adds a lot of trouble in development efforts, testing and bug fixing.
Still, it will be interesting to see how the fragmentation of Android devices evolve and how this will influence the attraction of developers providing Apps for the Android OS. Of course, having developers focusing only on certain Android OS versions and/or hardware characteristics could also make the hardware vendors streamline their hardware specs and OS versions. Selling Android devices which show only very few apps on the Android Market might not sell so well after all.
Over the time, I have collected some links to websites and articles with topics interesting for Software Architects. Since they might be of interest for others, too, I am providing them here for you. If you also have some links which you think are interesting for other Software Architects, please let me know.
MSDN features an article covering reasons why and how managed applications can suffer from memory leaks, how you can find them and get rid of them:
Despite what a lot of people believe, it’s easy to introduce memory and resources leaks in .NET applications. The Garbage Collector, or GC for close friends, is not a magician who would completely relieve you from taking care of your memory and resources consumption.
I’ll explain in this article why memory leaks exist in .NET and how to avoid them. Don’t worry, I won’t focus here on the inner workings of the garbage collector and other advanced characteristics of memory and resources management in .NET.
It’s important to understand leaks and how to avoid them, especially since they are not the kind of things that is easy to detect automatically. Unit tests won’t help here. And when your application crashes in production, you’ll be in a rush looking for solutions. So, relax and take the time to learn more about this subject before it’s too late.
Nice introduction into Node.js: The Node Beginner Book » A comprehensive Node.js tutorial http://t.co/BMbv5AE3 (via Instapaper)Very nice! Now everything is OK :-)
The magic button — Make Everything OK http://t.co/L1xodIWaGreat article about apps being designed as Augmented Paper by Matt Gemmell http://t.co/xQC7Jcgm (via Instapaper)
follow: RSS Tweet with me
