I like MVVM. The whole Idea of separating the view logic from the view is awesome and really fits into the Silverlight / WPF (I will refer to them as XAML from now on) world. As with every technology there are ups and downs and so has XAML its own downs. Two of them I want to explain here and show solutions for them.

String parameter passing for PropertyChanged events.

This problem will be gone with the next .NET version. The problem is that the compiler doesn’t check string contents . Lets assume you have the following class:

public class ContactViewModelTraditional : INotifyPropertyChanged
{
	private string _Name;
	public string Name
	{
		get
		{
			return _Name;
		}
		set
		{
			bool changed = value != _Name;
			_Name = value;
			if (changed)
				OnPropertyChanged("Name");
		}
	}

	public event PropertyChangedEventHandler PropertyChanged;

	private void OnPropertyChanged(string propertyName)
	{
		if (PropertyChanged != null)
			PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
	}
}

If you now want to change the property name “Name” to something else you have to think of the string parameter for the OnPropertyChanged method. If you forget to rename this string the compiler will not complain. You can see your error only at runtime (if you are lucky).

To solve this issue Microsoft has introduced the [CallerMemberName] attribute to make the parameter generated automatically.
For now, as we don’t have such a feature, I have chosen to (mis)use Lambda expressions to pass the property name. This way costs performance but ensures that the property name is correct or the compiler will detect it.

The class from above would look like this using my approach (I will explain the function call to “SetPropertyValue” later):

public class ContactViewModelTraditional : INotifyPropertyChanged
{
	private string _Name;

	public string Name
	{
		get
		{
			return _Name;
		}
		set
		{
			this.SetPropertyValue(p => p.Name, ref _Name, value);
		}
	}

	public event PropertyChangedEventHandler PropertyChanged;

	private void OnPropertyChanged(string propertyName)
	{
		if (PropertyChanged != null)
			PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
	}
}

The key in this example is the setter of the Name property. Here you can see that the name of the property gets passed as a Lambda expression. The “SetPropertyValue” method then has to get the name from the lambda expression and pass it to the “OnPropertyChanged” method.

Property dependencies and raising the correct PropertyChanged events

Another big problem arises when the ViewModel structure gets more complex and / or if properties are based on other properties and only change implicitly.

So lets assume we have a simple ViewModel and this ViewModel contains a ContactViewModel. We want a property “CurrentContactNameString” on the ViewModel that returns the Name of the current contact or the string “No Contact selected” if there is no current contact.

The ViewModel would look like this:

public class MainViewModelTraditional : INotifyPropertyChanged
{
	private ContactViewModelTraditional _CurrentContact;
	public ContactViewModelTraditional CurrentContact
	{
		get
		{
			return _CurrentContact;
		}
		set
		{
			bool changed = _CurrentContact != value;
			if (changed)
			{
				if (_CurrentContact != null)
					_CurrentContact.PropertyChanged -= CurrentContact_PropertyChanged;
				_CurrentContact = value;
				if (_CurrentContact != null)
					_CurrentContact.PropertyChanged += CurrentContact_PropertyChanged;
				OnPropertyChanged("CurrentContact");
				OnPropertyChanged("ContactNameString");
			}
		}
	}

	void CurrentContact_PropertyChanged(object sender, PropertyChangedEventArgs e)
	{
		if (e.PropertyName == "Name")
			OnPropertyChanged("ContactNameString");
	}

	public string CurrentContactNameString
	{
		get
		{
			if (CurrentContact != null)
				return CurrentContact.Name;
			return "No Contact selected";
		}
	}

	public event PropertyChangedEventHandler PropertyChanged;

	private void OnPropertyChanged(string propertyName)
	{
		if (PropertyChanged != null)
			PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
	}
}

You can see many “problems” in this little example:

1. Event passing between INotifyPropertyChanged instances
   You can clearly see in the setter of the CurrentContact property what has to be done if you rely on data inside a “foreign” INotifyPropertyChanged instance.
   You have to make sure to listen to the PropertyChanged event of the instance to set and remove the event handler from the instance that leaves.
   If you e.g. forget to remove the event handler from the “old” instance then you will get too many change-events. It’s very hard to detect something like this.
2. The property logic is spread all over the class
   To fire the correct PropertyChanged events the source of the event has to know exactly what properties rely on it.
   In this example the setter for “CurrentContact” and the event handler for the “Name” property of the current contact have to know that the property “CurrentContactNameString” uses them. In this example the dependencies are relatively simple but if this gets more complex you easily loose the overview.
   Every change on the target implies a reorganization of all the PropertyChanged sources to match the used logic again.

Results only change if the data used to get it changes

For those two problems I have developed a dependency tracking system. The central idea is that every result only changes whenever any data changes that has been used to get the result.
Sounds simple, right? It is that simple!

So I have developed a tracking mechanism that tracks all data that gets used to get a result (finally for a property getter). Whenever data changes all PropertyChanged events for results that depend on this data get fired.

The ViewModel sample using this approach looks like this:

public class MainViewModel : IFireNotifyPropertyChanged
{
	private ContactViewModel _CurrentContact;
	public ContactViewModel CurrentContact
	{
		get
		{
			using (this.Track(p => p.CurrentContact))
				return _CurrentContact;
		}
		set
		{
			this.SetPropertyValue(p => p.CurrentContact, ref _CurrentContact, value);
		}
	}

	public string CurrentContactNameString
	{
		get
		{
			using (this.Track(p => p.CurrentContactNameString))
			{
				if (CurrentContact != null)
					return CurrentContact.Name;
				return "No Contact selected";
			}
		}
	}

	public void FireNotifyPropertyChanged(string propertyName)
	{
		if (PropertyChanged != null)
			PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
	}

	public event PropertyChangedEventHandler PropertyChanged;
}

As you can see the property “CurrentContactNameString” only has to use the “CurrentContact” and the “Name” property. Whenever one of them changes the PropertyChanged event for “CurrentContactNameString” gets fired.

The integration of the framework is relatively simple:

1. every getter (that is relevant) uses a Tracker instance as long as relevant data gets accessed. The creation of this Tracker instance is hidden by a extension method “Track” for INotifyPropertyChanged.
2. setter have to use the SetPropertyValue extension that triggers all the logic to notify dependent properties about this change
3. (Only Silverlight for now) Instead of INotifyPropertyChanged the classes have to implement IFireNotifyPropertyChanged which extends INotifyPropertyChanged by a method to trigger a PropertyChanged event. This is necessary because Silverlight doesn’t allow to access private fields through reflection (and this is the only way to trigger an event from outside an instance)

The downside of this framework is that it can get slow very fast. Because every change triggers the PropertyChanged event for all dependent properties the amount of triggered events can explode easily. So use it with care
The real benefit is that you don’t have to care about dependencies between Properties or INotifyPropertyChanged instances and – even more important – don’t have to think about them during a refactoring!

I will explain the implementation of this framework in the next post after I have reorganized and published it to some Open Source hoster. So stay tuned

Devmil

I have been a .NET guy almost since I started developing software.

The beginning: Delphi

After finishing high school I started developing in Delphi during my vocational training. In my free time I came across the .NET Framework 1.1 (2003) and fell in love with it. From that very moment on I tried to use .NET and especially C# whenever I had the oportunity to do so. After finishing my vocational training in the end of 2003 I began to study computer sciences. The University of Applied Sciences I have been at had a very strong C and Java focus so C# was limited to my fun projects and my little side business I started to finance my studies.

My first mobile contact

At this time I discovered Windows Mobile and was blown away by the possibility to develop applications using C# for my handset. I developed many little applications for my handset and had much fun. One of those fun projects has been SniffThat.
I also worked as a freelancer for some firms. The most important condition for me to offer my work has been – you guess it – .NET. I always had the choice so every time I looked for a job I found one that had .NET involved. And sometimes I have found one that involved .NET and Windows Mobile. I have been a very happy jung man

After finishing my studies (2007) I hired at a company that – you already know this – develops applications using the .NET Framework. Mainly ASP.NET intranet business applications. I had a very good time there, learned very much about clean code, performance optimizations and databases.
But something in my mind told me to try something different. I don’t know if I have been bored by the business requirements (finance) or if the birth of our first child triggered considerations regarding our long term future. I don’t know. Propably a mixture.

So 2011 I hired at a company to develop embedded software (user interfaces for home appliances). A complete new world. C++, embedded software, a big company.

My way to Android

Around 2008 I had lost my focus on handsets. I had a “standard” phone (Sony Ericcsson I think) and did some Silverlight stuff in my free time. At one day my brother showed me his cool new phone: An iPhone. He told me that this phone has Apps, has nice specs and everybody needs one.
I checked the options to develop for this new handset and discovered some things that I didn’t like on developer side.
The two things that finally hold me off have been

1. It is an Apple product. Come on! I only knew few people using Apple computers at this time. And these few people were so proud of beeing able to spend so much money for their computer that they had to show and tell this to everybody. I really hate that.
2. Pay 100 bucks a year and buy a Mac only to develop for a phone as a hobby? Err – no.

A year or so later – after he almost bricked it trying to jailbreak – he bought another phone. This phone – so he said – is based on Linux and much more open than Apples iOS. He showed me his new Motorola Milestone. I liked the progress this techology has made since my Windows Mobile days and decided to get such a phone for my next contract renewal.

This is how I got my Galaxy S. I found out that the development for Android is based on Java (not so good) and is free (very good). I developed some little sample apps and started to rebuild an app called Clockr. A clock widget that shows the clock as text. After I had replicated Clockr I started to improve it. Added multiple language support, some settings here, some settings there, a layout editor and that is the story of Minimalistic Text.

My current way back

So, O.K. you may ask. What the heck has this story to do with the title of this post? I will tell you:

Before I bought the Galaxy S I checked what Microsoft will do with their Windows Mobile (that wasn’t able to compete with iOS or Android). As a C# fanboy I would have taken some drawbacks as a tradeoff to develop apps in C#. I found out that they (Microsoft) are going to use the “Apple approach”.
“If you like to load your own apps onto your own phone please give us 100 bucks a year”.
“If you don’t want me, you don’t get me” I thought and ordered the Galaxy S. Man I have been pissed off.

In the beginning of 2012 – Minimalistic Text is over a year old – I have a small business again (for the donations that come for Minimalistic Text and some jobs that came alive through Minimalistic Text) the rumors about Windows (Phone) 8 are getting louder and louder so I started to look into the Windows Phone world again. I really turned off all Windows Mobile / Windows Phone related RSS feeds because I have been so damn pissed off. So I didn’t get any news about Windows Phone. I realized that Windows Phone has progressed (Copy and Paste, some kind of multithreading, …) and that if Microsoft can get back into the smartphone game then with the help of Windows 8 on PCs, Tablets and Smartphones.

Driven by the never dying love for C# I decided to prepare for Windows 8 by playing around with Windows Phone 7 and ordered a Samsung Omnia W.

I have to say that I have been amazed by this phone. I have a Galaxy Nexus right here on the desk but this little Omnia W smokes the Galaxy Nexus regarding smooth animations / transitions and overall response behavior.
Windows has its drawbacks – no doubt. The biggest one is that googlemail emails can’t be starred on the phone (sorry if I didn’t respond to some emails the past 2 months) and that you can’t access the file system (from your phone and from your computer).
But despite these drawbacks I use my Omnia W since I got it as my daily driver. My Galaxy Nexus is in my backpack as a backup I simply can no longer ignore this micro stuttering when swiping through the home screen or app drawer.

Today I know that one can earn those 100 bucks in one year with some Marketplace activity so this argument isn’t that heavy any more. I don’t like it because I think that many hobbyists are held off developing for Windows Phone, but I can live with it.

So to explain this blog title: I’m currently developing some fun apps for Windows Phone using C#. So expect some technical C# / Silverlight / Windows Phone posts in the near future.

And if Microsoft does some things right then I will be very glad to provide some apps for the Windows Phone 8 marketplace.

Ah, and don’t worry: I will continue developing Minimalistic Text. The user base is too big and I am too proud of it to leave it behind

While developing an app that needs to interact with the operating system, like Minimalistic Text, every Android developer will get to a point where the Android fragmentation hits him. Sometimes a little bit and sometimes hard
Minimalistic Text has such a “problem” since the beginning and today I want to explain what the problem is and what I did to resolve this annoying issue.

Widgets in Android

Widgets in Android get updated through packages that are sent from the application. The application can’t control directly what the widget does but it can throw settings into such a package and send it to the widget. The Launcher app then receives this package and applies it to the widget.
Due to the things Minimalistic Text can do (shadows for example) the options that such a package offers aren’t enough to bring all the settings that a user has set up to the widget.
So Minimalistic Text uses the “Bitmap approach”. The content of the widget gets rendered into a bitmap and then the bitmap gets passed to the widget (through the package). The widget itself is only an ImageView.
This approach works really well. At least on most devices. And at least for certain widget sizes… The story begins.

The problem

From the launch of Minimalistic Text until today there are complaints from users that told me that their widget stops updating. After some investigation I have found out that the package size that the app can send to the widget is limited. I think 1 MB is the maximum. If the app sends a package bigger than that limit the update will fail. The really bad thing is that the app doesn’t notice this. So the update silently fails and Minimalistic Text doesn’t know of any problem.
I worked around this issue by reducing the available widget sizes. If you want to get this problem then simply create a 4×2 Minimalistic Text widget and fill it with data so that the image that has to be sent to the widget gets as big as possible.
The only way to avoid sending such a big image through a package is to save the image as a file and only send an URI to the widget where to find it. Sounds great, doesn’t it?
I have tested this approach on my HTC device and it worked great. So I decided to publish my new bugfix into the wild and shortly after that a e-mail flood has arrived my googlemail account. Many users complained about widgets that are scaled down.
After rolling this bugfix back and googleing around a bit I found out that there is a bug in Android. If the Bitmap isn’t applied directly to a ImageView but through an URI (that gets fed by a ContentProvider) the image gets scaled down by the density of the screen.

Fragmentation everywhere

And here comes the fragmentation into play.
If this bug would be on all devices – not cool but no problem. Minimalistic Text could simply scale the image up so that the bug scales it down again and everything is fine. Well would be is the right term
It seems like some vendors have fixed this bug (for some of their devices). I have a HTC Sensation that doesn’t scale anything. My Galaxy Nexus and the Nexus S do. So thanks to the fragmentation I have no clear way without a bug or with a workaround for this bug.
Pissed off by the fact that my fix doesn’t work on all devices I took this problem as beeing present and limiting the amount of widget sizes that Minimalistic Text can handle.

And it gets worse

As the screen resolutions get bigger and bigger the 1 MB limit comes nearer and nearer. The last days some people had the “widget doesn’t update any more” issue on 4×1 widgets.
So I had to find any way to avoid this issue.

The solution

After telling this a colleague of mine and complaining about the “bad bad” Android fragmentation and how developing for Android is like creating big if cascades to check what device is currently executing the app to activate special workarounds or hacks he asked me if it was possible to get the bytes that are displayed on the widget to check if they were scaled or not.
After coming home and bringing the kids to bed I tried to use my own ContentProvider and then checked if the image that the ImageView got from the ContentProvider has been scaled. And yes, it did. So now I have found a way to measure this bug and scale the images for the widgets the same way up as they get scaled down by the ImageView.

Dead simple.

To give you an idea of how to achieve this I will post some source code here. So if you aren’t a developer this place can be a good one to stop reading this post

Some code

The first step is to make your ContentProvider “Sample”-aware. Use some kind of special data to signal the ContentProvider that you need a specified sample image.
I have added the following functions to the Minimalistic Text ContentProvider (the source code is not functional as it is only part of a bigger source file):

public static final Uri CONTENT_URI = Uri.parse("content://"
        + PROVIDER_NAME + "/widgets");

private static String getSampleFileName() {
    return "MT_Sample.png";
}

public static int getSampleRectangleSize()
{
    return 100;
}

public static Uri ensureSampleBitmap(Context context) throws IOException {
    Uri result = Uri.parse(CONTENT_URI.toString() + "/-1/"
            + Long.toString(Calendar.getInstance().getTimeInMillis()));

    File file = new File(context.getFilesDir(), getSampleFileName());
    if (file.exists())
        return result;
    FileOutputStream fOut = context.openFileOutput(getSampleFileName(),
            Context.MODE_WORLD_READABLE);
    Bitmap sampleBitmap = Bitmap
            .createBitmap(1, 1, Bitmap.Config.ARGB_8888);
    sampleBitmap.setPixel(0, 0, Color.WHITE);
    Bitmap scaledBitmap = Bitmap.createScaledBitmap(sampleBitmap, 
                                    getSampleRectangleSize(), 
                                    getSampleRectangleSize(), false);
    scaledBitmap.compress(CompressFormat.PNG, 100, fOut);
    fOut.flush();
    fOut.close();

    sampleBitmap.recycle();
    scaledBitmap.recycle();

    return result;
}

This methods allow us to create a sample image that has a dimension of 100×100 and get an URI to retrieve the image.
The code for the openFile method of the ContentProvider looks like this:

@Override
public ParcelFileDescriptor openFile(Uri uri, String mode)
        throws FileNotFoundException {

    try {
        int widgetId = Integer.parseInt(uri.getPathSegments().get(1));

        File file = null;

        //thie widgetId -1 signals "Sample data"
        if (widgetId == -1) {
            file = new File(getContext().getFilesDir(), 
                    getSampleFileName());
        } else {
            file = new File(getContext().getFilesDir(),
                    getFileName(widgetId));
        }

        return ParcelFileDescriptor.open(file,
                ParcelFileDescriptor.MODE_READ_ONLY);
    } catch (Exception e) {
        return null;
    }
}

Now the app can measure the amount of wrong scaling by instantiating an ImageView and let the ImageView fetch the sample image:

private float calculateImageContentProviderScale()
{
    try {
        ImageView imgView = new ImageView(this);
        imgView.setImageURI(
            WidgetImageContentProvider.ensureSampleBitmap(this));
        
        imgView.measure(MeasureSpec.UNSPECIFIED, MeasureSpec.UNSPECIFIED);
        
        return (float)WidgetImageContentProvider.getSampleRectangleSize() 
                / (float)imgView.getMeasuredHeight();
    } catch (IOException e) {
        Log.e(TAG, "Error determining the image scale factor", e);
        e.printStackTrace();
    }
    return 1;
}

This factor can be stored as a static variable because this value won’t change during the app lifetime.
Everytime a widget gets updated Minimalistic Text now uses this factor to scale the image up.

ContentProvider-Part:

public static Uri updateWidget(Context context, Bitmap widgetContent,
        int widgetId, boolean useSalt, float scaleFactor)
        throws IOException {
    String fName = getFileName(widgetId);
    FileOutputStream fOut = context.openFileOutput(fName,
            Context.MODE_WORLD_READABLE);
    
    Log.d(TAG, "Using a scale factor of " + Float.toString(scaleFactor));
    
    if(scaleFactor > 1)
    {
        float scaledHeight = widgetContent.getHeight() * scaleFactor;
        float scaledWidth = widgetContent.getWidth() * scaleFactor;

        Bitmap scaledWidgetContent = Bitmap.createScaledBitmap(
                                                widgetContent, 
                                                (int)scaledWidth, 
                                                (int)scaledHeight, 
                                                true);
        scaledWidgetContent.compress(CompressFormat.PNG, 100, fOut);
        fOut.flush();
        fOut.close();
        scaledWidgetContent.recycle();
    }
    else
    {
        widgetContent.compress(CompressFormat.PNG, 100, fOut);
        fOut.flush();
        fOut.close();            
    }

    return Uri.parse(CONTENT_URI.toString()
            + "/"
            + Integer.toString(widgetId)
            + "/"
            + (useSalt ? Long.toString(Calendar.getInstance()
                    .getTimeInMillis()) : ""));
}

Client-Part:

Bitmap textBitmap = createTextBitmap(context, settings,
        demoMode, ss.hasBeenPortrait(), events);

Uri imgUri = WidgetImageContentProvider.updateWidget(
                        context, 
                        textBitmap, 
                        settings.getAppWidgetId(), 
                        true, 
                        ss.getImageScale());
remoteView.setImageViewUri(R.id.imgContent, imgUri);
textBitmap.recycle();

I hope this helps any poor developer out there that has been stuck on the same problem as I have been until today!
If you have any further questions, simply write me an email.

Devmil

I will change the way this blog works a bit. I want to blog more into the “software development” / “Android” direction than about my personal day to day drivers. Also I have the plan to rise the update frequency of this blog and the language changed to English so that users outside Germany can read what I write

So let’s start off with a little Android exercise. Recently I implemented a new language selector for Minimalistic Text. The old one just used the ListPreference in the Android Settings. My main goal has been to add little flags to each language to make this dialog a little more colored.

A short research on the internet showed me that there is no way to get images into a ListPreference. So I had to implement my own Preference that is capable of a list with images.
My first thought was to derive from ListPreference and add the image functionality. But due to the (lack of) design in the ListPreference there is no way to derive a subclass that implements another visual part. The main reason for this is the fact that the ListPreference stores the selected element index into an internal variable (private) that then gets read by the dialog closed event. So a subclass would have to set the index based on its own view to use the ListPreference functionality like propagating the settings change to all listeners.

So the last possibility has been to copy the ListPreference code to my own class and make images in the list possible.

The solution constists of 6 files:

• ImageListPreference.java
• ImagePreferenceArrayAdapter.java
• imagelistpreferencelayout.xml
• empty_content.xml
• orange_content.xml
• clickbackground.xml

Language Selector

Ich habe für Minimalistic Text ein Wiki eingerichtet. Die Idee ist dass User dort ihre Tipps / Anleitungen / Einstellungen verewigen und mit der Community teilen können. Ich bin gespannt, ob das Wiki Anklang findet.

Das Minimalistic Text Wiki ist unter http://wiki.devmil.de erreichbar.

Devmil

Also habe ich alle zusammen in einen Farbauswahldialog gesteckt. Über Tabs kann man sich entscheiden, ob man lieber HSV, RGB oder den HEX Code als Eingabemöglichkeit vorzieht. So sieht er dann in Aktion aus:

Falls Ihr ihn verwenden oder sogar daran mitentwickeln wollt: Der Source Code ist hier zu finden.

Devmil

Minimalistic Text

Der Release von Minimalistic Text verlief sehr gut. Inzwischen sind es über 20000 Downloads und fast 10000 aktive Installationen. Die letzten Wochen hat sich auch einiges an Minimalsitic Text getan. Mehrsprachigkeit, Statischer Text, Wetterdaten und viele weitere Verbesserungen sind bereits eingeflossen.

Das kleine Spaßprojekt ist schon fast zur Feierabend-Arbeit mutiert und nimmt momentan fast jede Minute ein, die ich am Rechner verbringe. Es wollen E-Mails mit Fragen beantwortet, Forenbeiträge geschrieben und Erweiterungen entwickelt werden. Nichtsdestotrotz macht es mir nach wie vor Spaß die App weiterzubringen.

Ich konnte dank der App bereits sehr viel über die Android Entwicklung lernen und wie in anderen Programmiersprachen / auf anderen Plattformen auch, lernt man nie aus und ständig was Neues.

Wen man Annahmen über die API hinaus trifft…

Vor ein paar Tagen gab es Probleme mit Minimalistic Text auf bestimmten, neueren JPU-Roms für das Samsung Galaxy S I9000. Minimalistic Text hat einfach den Start verweigert, bzw. kein Widget mehr als “existent” betrachtet.

Nach einigem Hin und Her und einer E-Mail Konversation mit einem betroffenen konnte ich dem Problem auf den Grund gehen:

Hintergrund ist die Tatsache, dass man in Android zwar Einstellungsdateien (Shared Preferences) anlegen, aber nicht mehr löschen kann. Jedes Widget in Minimalistic Text besitzt eine eigene Einstellungsdatei, so dass “Datenmüll” übrig bleibt, wenn man ein Widget löscht. Minimalistic Text “weiß” wo diese Einstellungsdateien liegen und löscht diese, wenn ein Widget vom Homescreen entfernt wird.

Außerdem hatte ich temporär das Phänomen, dass Widget-Ids zwar noch vorhanden waren, die zugehörigen Widgets aber schon längst vom Homescreen entfernt wurden. Um unnötiges Aktualisieren von nicht mehr sichtbaren Widgets zu verhindern prüft Minimalistic Text, ob ein Widget noch da ist, indem es prüft, ob es noch eine Einstellungsdatei dazu gibt.

Diese beiden “Features” basieren darauf, dass die Einstellungsdateien unter “/data/data/de.devmil.miniamaltext/shared_prefs” liegen.
Tun sie auch, bei (fast) allen mir bekannten Geräten. Nur eben nicht in den neuen Samsung ROMs.

Ist ja auch nichts verwerfliches. Die API der Shared Preferences oder des Contexts gibt auch keinen Pfad zu diesen Einstellungsdateien, so dass die Annahme des Speicherplatzes schon etwas gewagt war, wenn man bedenkt wie viele unterschiedliche Android Geräte es gibt.

Auf jeden Fall prüft Minimalistic Text jetzt, ob es das vermutete Verzeichnis überhaupt gibt. Wenn nicht, dann wird in den “mir doch egal”-Modus gegangen und jede WidgetId als vorhanden angenommen und die Einstellungsdatei nur geleert, nicht aber gelöscht.

Für das Samsung ROM habe ich inzwischen herausgefunden wo die Einstellungsdateien liegen, da ich jetzt auf die Version JPX (ebenfalls Android 2.2.1) gegangen bin und die das gleiche Verhalten zeigt.

Anscheinend hat Samsung aus Performance-gründen die Shared Preferences von “/data/data/<Package>/shared_prefs” nach “/dbdata/databases/<Package>/shared_prefs” umgezogen.

Die nächste Minimalistic Text Version wird dieses Verzeichnis auch in Betracht ziehen.

Minimalistic Text heißt sie und versteht sich als Meta-Widget zur Darstellung von Information auf eine minimalistische Art und Weise. Derzeit werden Zeit-, Datums und Akkuinformationen verarbeitet und dem User in Form von Variablen zur Verfügung gestellt.

Der User kann sich mit Hilfe des Layout Editors die Variablen so zurechtlegen, wie er es gerne hätte. Pro Widget lassen sich dann noch die Styles der Schriften anpassen und schon hat man ein individuelles Widget.

Für die Zukunft ist, neben vielen anderen Erweiterungen, geplant, noch mehr Informationsquellen einzubinden (Wetter z.B.). Außerdem wird es die Möglichkeit geben die Sprache pro Widget einzustellen (derzeit fest Englisch).

So sieht das Werbe Bild aus

XDA-Forumsbeitrag (von mir)
AppBrain-Link
Markt-Link (funktioniert nur vom Android Handy aus)

Hier gibt es eine sehr knappe Hilfe zu Minimalistic Text (auf Englisch)

Ich habe meinen Androiden (Samsung Galaxy S I9000) jetzt seit ca. einem Monat und arbeite mich Tag für Tag tiefer in die Materie “Android” ein.
Anfang des Monats stand für das Galaxy S ein Update auf FroYo (Android 2.2) an. Zu Glück noch bevor bevor die Version 2.3 (Gingerbread) erschienen ist Dadurch habe ich die Update Thematik hautnah miterlebt.

Android ist kein Eigentum von Google, sondern offiziell eine Art Zusammenarbeit verschiedener Hersteller. Der Quellcode ist offen und kann von jedermann eingesehen werden. Die einzelnen Hersteller nehmen diesen Source Code als Basis und stricken eine mehr oder weniger dicke, eigene Schicht darüber (z.B. Hardwaretreiber, spezielle Apps, …). Dann sind da noch die Netzbetreiber die das Android vom Hersteller bekommen und wiederum ihre Besonderheiten einbauen (Werbe-Apps, Theme, Mobilfunkeinstellungen, …).

Man sieht schon: Der Weg ist lang. Aber da hört das Problem noch nicht auf. Die Hersteller arbeiten (verständlicher Weise) gewinnorientiert. Wenn jetzt so ein Handy in die Jahre (oder Monate, wie bei Motorola) kommt, dann wird irgendwann der Support eingestellt. Da nützt es herzlich wenig dass von Google vorangetrieben eine neue Version von Android bereit steht. Wenn der Hersteller keine Treiber dafür anpasst, dann gibt es eben kein Update.
Das Problem heutzutage ist, dass die Systeme (auch auf den Smartphones) viel zu komplex sind als dass sie mit sehr wenigen oder sogar gar keinen Updates auskommen würden. Jeder der auf seinem Rechner Windows, Linux oder MacOS installiert hat, der wird sicher feststellen dass da das ein oder andere Mal Updates zur Verfügung stehen. Diese Updates machen die Betriebssystemhersteller nicht zum Spaß, sondern meistens um Fehler oder gar Sicherheitslücken auszumerzen.
Was macht nun also so ein Motorola Android Besitzer, für den Motorola keine Updates mehr bereit stellt? Dia Apps kann er noch aktualisieren, aber alles was zum Betriebssystem gehört bleibt (normalerweise) so, wie es ist.
Stellt sich also heraus, dass der Android Browser eine Sicherheitslücke hat, dann wird diese Lücke bleiben. Für immer.

An dieser Stelle bleibt dem Android-Besitzer, dessen Support eingestellt wurde, nur der Gang zu diversen einschlägigen Seiten (die bekannteste davon ist wohl XDA-developers.com) in der Hoffnung, dass dort ein paar schlaue Entwickler sitzen die genau das gleiche Handy haben (oder eine Herausforderung brauchen) und das neue Android für das Gerät anpassen.

Erkläre das mal deinem Opa (Ausnahmen bestätigen natürlich die Regel ).

Derzeit kann man also nur sagen: Android – ja, ohne Zweifel, wenn du ein Power User bist oder werden willst und – nein, auf keinen Fall, wenn du einfach nur ein Handy brauchst, mit dem du telefonieren und ab und an mal E-Mails checken willst.

Devmil

in diesem Blog wird es um meine Erfahrungen / Meinungen rund um das Thema Softwareentwicklung und im speziellen um Programmierung auf mobilen Endgeräten gehen.
Der Blog hat kein streng abgegrenztes Thema wie “.NET Entwicklung” oder “Android Entwicklung” sondern beschäftigt sich mit den Themen, mit denen ich mich gerade beschäftige. Und das kann je nach Lust, Laune und Gegebenheit auch mal wechseln.

Erst neulich ist so eine Kehrtwende passiert.
Die letzten Jahre hat sich sowohl in der Arbeit als auch privat alles, was programmieren anbelangt, um .NET und C# gedreht. Auch die Auswahl meiner Handys war ohne Debatte auf Windows Mobile festgelegt, da ich dafür mit .NET relativ einfach programme schreiben konnte.
Vor ein paar Monaten hat sich in mir eine Neugierde nach etwas anderem entwickelt, die immer ausgeprägter wurde. Diese Neugierde zusammen mit einem anstehenden Jobwechsel und zu guter letzt die Details, die über Windows Phone 7 bekannt geworden sind, haben mich dazu gebracht meinen Blick von .NET und C# zu lösen und mein mobiles Gerät unabhängig der benötigten Programmiersprache, sondern abhängig von dem Mehrwert / Nutzen den es mir bringt und den Möglichkeiten die ich damit habe, auszuwählen.
Am Ende ist es dann ein Android Handy geworden. Genauer: Ein Samsung Galaxy S I9000
Meine Entscheidung hat ihre Ursachen sowohl aus der Sicht eines Entwicklers als auch als der Sicht eines Power Users:

Entwicklersicht:

• Für Android muss der Entwickler kein Geld bezahlen, um ein selbstgeschriebenes Programm auf sein Gerät zu bringen. Kein Witz! Kein Geld! Hintergrund dieser Aussage: Apple und Microsoft verlangen von Entwicklern, die doch tatsächlich ihr Programm auf dem Handy ausführen wollen, dass sie registrierte Entwickler werden. Das kostet dann so 100$ / Jahr. Für Google muss man erst bezahlen (und auch nur moderate 25€, einmalig) wenn man seine Anwendung im Google Market anbieten will.
• Anwendungen haben in Android mehr Möglichkeiten. Ein Programm kann ohne groß Aufwand zu betreiben, einen Hintergrunddienst starten um z.B. irgendetwas zu aktualisieren, GPS zu tracken, … Sowas geht (zumindest so einfach) bei Microsoft und Apple nicht. Kann auch Vorteile haben, dazu später mehr in der Nutzersicht.

Nutzersicht:

• klar ist es ein Vorteil, wenn die Plattform an sich schon eine sehr große Sicherheit bietet um sicherzustellen dass sich Anwendungen korrekt verhalten und nicht unnötig Akku verschwenden oder private Daten ins Internet senden. Die interessante Frage an dieser Stelle ist der Preis dafür.
  Die Gefahr, dass sich Anwendungen “nicht korrekt” verhalten sehe ich auf Android schon etwas höher, da keine Instanz die Anwendung prüft. Auf der anderen Seite gibt es auch keine Instanz die Anwendungen auf Grund irgendwelcher firmenpolitischer Entscheidungen verhindert / aufhält (Flash + iPhone z.B.).
• Falls mal irgendwo ein Fehler enthalten ist (was ja in der Softwareentwicklung ab und an mal vorkommen soll) ist man mit Android “freier” im Sinne von “dann suche ich mir halt eine andere App, die den gleichen Job erledigt”. Dabei ist Android nicht auf die oberflächlichen Apps beschränkt, sondern dann wird halt schon mal der Home Screen oder die Gallerie getauscht. Erfordert mehr Auseinandersetzung mit dem Gerät, eröffnet aber auch deutlich mehr Möglichkeiten (aber: auch was falsch zu machen)

Im Endeffekt wird jeder für sich selbst entscheiden müssen, auf welche Aspekte er/sie mehr Wert legt. Ich für meinen Teil kann nur sagen, dass ich mich für Android entschieden habe.

Was ich eigentlich damit ausdrücken wollte: Dieser Blog kann innerhalb von Monaten eine Kehrtwende machen und sich in eine andere Richtung bewegen. Wie mein “Brain” halt auch.

Devmil