Die App ist mit dem Anliegen gestartet, ein möglichst einfacher Voice Recorder zu sein der das, was er tun soll so gut wie möglich macht. Zunächst ist die App darum mit zwei Funktionen gesetartet: Tonaufnahme und Tonwiedergabe.

Links sieht man wie das Ganze optisch aussieht: Namen für die Datei eingeben, auf   den großen Button mit dem Kreis drücken und los geht’s.

Die AL Voice Recorder Aufnahme-Activity

Die Datei wird dann standardmäßig auf der SD-Karte in dem Ordner ‘AL Voice Recorder’ abgelegt. Da ich nicht nur diesen, sondern alle Ordner des jeweiligen Android Handys auf Audiodateien durchsuchbar machen wollte, haben ich auch noch einen Dateibrowser entwickelt (s. Bild unten). Der Browser startet automatisch im Ordner ‘AL Voice Recorder’, es kann aber auch jede andere Directory angesteuert werden.

Die Browser-Activity des AL Voice Recorders

Über das Menü gerät man von dort aus, wie man auf dem Bild schon sehen kann, zu dem Fenster in dem neue Tonaufnahmen gemacht werden können.

Ständige Weiterentwicklung, Feedback erwünscht

Der AL Voice Recorder ist minimalistisch gestartet und wird kontinuierlich weiter entwickelt. Jeder Nutzer oder Interessent ist dazu aufgerufen, jederzeit Feedback abzugeben und neue Funktionen vorzuschlagen. Einige User haben das bereits getan und einige dieser Vorschläge wurden bereits umgesetzt.

Daher hier eine Übersichtsliste, welche Features bereits auf Euren Wunsch hin umgesetzt wurden und welche noch umgesetzt werden sollen (auf englisch):

Done:

• Delete auidiodata by longpress
• Send audiodata by longpress

Todo:

task, (difficulty),[comment]

• Develop plugin for mp3-encoding (difficult) [currently only AMR contained by a .3gp-container is supported]
• Implement widget (easy)
• Enable AL Voice Recorder to record calls (medium)

Sollten Ihr irgendwelche Ideen oder Verbesserungswünsche haben, hinterlasst mir einfach eine Nachricht in den Kommentaren

]]> http://andforge.net/2010/neue-app-al-voice-recorder/feed/ 1 http://andforge.net/2010/teleporter-prototyp-droidcon/ http://andforge.net/2010/teleporter-prototyp-droidcon/#comments Thu, 27 May 2010 22:53:26 +0000 Mohammed El Batya http://andforge.net/2010/teleporter-prototyp-auf-der-droidcon/ ]]> http://andforge.net/2010/teleporter-prototyp-droidcon/feed/ 3 http://andforge.net/2010/apps-au-sd-mit-froyo/ http://andforge.net/2010/apps-au-sd-mit-froyo/#comments Tue, 25 May 2010 10:30:30 +0000 Lukas.Jarosch http://andforge.net/2010/apps-2-sd-mit-froyo/ Wie ich in meinen vorherigen Post geschrieben habe, kann man nicht per default Apps auf die SD-Karte verschieben.

Dem kann jetzt ganz einfach abgeholfen werden

1: Über ADB...
Handy mit Aktiviertem USB-Debugging Modus mit dem PC verbinden und ADB Starten.

• adb shell
• pm setInstallLocation 2

2: Direkt auf N1
“therminal emulator” vom Market laden.
Therminal Emulator Starten und folgendes eingeben:

• su
• pm setInstallLocation 2

Getestet und funktioniert, viel Spaß.

P.S. kopiert nur Spiele und andere große apps die ihr nicht dauernd braucht. Widgets etc sollten auf dem Handy bleiben.

Wie in der Google I/O Keynote sind alle Features vorhanden und laufen wie angekündigt.

Hier http://forum.xda-developers.com/showthread.php?t=686627 könnt ihr sogar schon eine Root-Version runterladen (wie immer ohne Gewähr)

Erster Eindruck: solide

• Der Homescreen hat jetzt ein kleines Dock mit Telefon und Browser Shortcut bekommen.
• Das Gerät lässt sich jetzt in beiden Richtungen im Landscape Modus benutzen, sprich nur noch kopfüber Portrait gibts nicht.
• Der AppMarket hat jetzt ein Widget bekommen.
• Wunderschön und einfach ist auch das erstellen eines Accesspoints.
• Was ein bißchen entäucht ist das kopieren von Apps auf die SD Karte. Zwar ist dieses Feature enthalten, jedoch muss jeder Entwickler explizit angeben das er das erlaubt was wiederum heißt das er erst auf die API 2.2 wechseln muss ….. und das haben bis jetzt die wenigsten gemacht.

Fazit: Stark positiv und ein Update zu Froyo ist auf jeden Fall zu empfehlen!

Postet eure Erfahrungen in den Comments!

Ich möchte mit diesem Artikel einen grundlegenden Überblick über die Programmierung eines solchen Live Wallpapers vermitteln.
Dieser Artikel enthält keinen voll funktionstüchtigen Code, da bereits ein gutes Beispiel im SDK 2.1 (namens “Cube”) mitgeliefert wird.

Vom Prinzip her ist so ein Live Wallpaper ( ab jetzt LWP abgekürzt ) das selbe wie eine normale Activity, welche auf einem 2D Surface einfache Dinge wie Kreise und und Linien zeichnet. Es ist vergleichbar mit der Programmierung eines kleinen 2D Spiels.

Voraussetzungen für dieses Tutorial:

• Du hast schon mal eine normale Activity programmiert.
• Du hast das SDK 2.1 installiert.

0. Grundlagen

Ein LWP besteht im Grunde aus 5 Teilen:

1. einem WallpaperService
2. einer “Engine”, welche sich um das Zeichnen kümmert
3. einer “Einstellungen”-Activity zur Anpassung des Wallpapers durch den User (z.B. Farben)
4. einer XML-Datei um zu konfigurieren wie das LWP aufgelistet wird (z.B. Icon)
5. das übliche Android-Manifest

1. Der WallpaperService

Zunächst benötigst du eine Klasse, welche von “WallpaperService” erbt. In dieser Klasse musst du nur die Methode “onCreateEngine()” überschreiben und deine eigene Engine zurückgeben.

public class AndforgeWallpaper extends WallpaperService {
	@Override
	public Engine onCreateEngine() {
		return new AndforgeLWPEngine();
	}
}

2. Die Engine

Die Engine übernimmt das eigentliche Zeichnen und muss innerhalb deines WallpapersServices definiert werden. Also definieren wir als nächstes eine innere Klasse, welche von WallpaperService.Engine erbt.

public class AndforgeWallpaper extends WallpaperService {
	@Override
	public Engine onCreateEngine() {
		return new AndforgeLWPEngine();
	}

	 class AndforgeLWPEngine extends Engine{
		// TODO: ausprogrammieren
 	}
}

Die Engine besitzt einen SurfaceHolder, welcher wiederum ein Canvas besitzt. Auf diesem Canvas kann man letztendlich seine Animationen zeichnen. Mit der Methode getSurfaceHolder() bekommt man in der Engine das Surface. Wendet man auf das Surface die Methode lockCanvas() an bekommt man das Canvas zum zeichnen.

Achtung: Es ist wichtig das Canvas über die Methode lockCanvas() zu erhalten, da es sonst zu seltsamen Fehlern kommen kann. Dies hat unter anderem damit zu tun, dass “DoubleBuffering” eingesetzt wird.

DoubleBuffering?
Kurz gesagt: Es werden zwei Bilder generiert, eines auf dem gerade gezeichnet wird und eines, welches auf dem Bildschirm zu sehen ist. Diese Bilder werden nach jedem Zeichenvorgang ausgetauscht, was bedeutet, dass man immer eine “alte” Version des Bildes zum Zeichnen bekommt. Ruft man nun lockCanvas() auf bekommt man das Canvas, welches gerade nicht angezeigt wird um darauf zu zeichnen. Ist man fertig mit dem Zeichnen kann man mit unlockCanvasAndPost(canvas) das Canvas wieder freigeben und ein Austauschen des angezeigten Canvas mit dem frisch bemalten Canvas anstoßen.

Das Zeichnen sieht dann ungefähr so aus:

Canvas canvas = getSurfaceHolder().lockCanvas();

//TODO: auf dem canvas zeichnen

getSurfaceHolder().unlockCanvasAndPost(canvas);

Wo stecken wir nur unseren Code zum Zeichnen hin? Theoretisch kann man jetzt eine beliebige Methode der Engine überschreiben und dort etwas zeichnen (was nicht immer sinnvoll ist ^^). Es ist wichtig zu verstehen, dass die Engine einen Lifecycle (Lebenszyklus) durchlebt. Das bedeutet, dass es z.B. Momente gibt in denen es gar keinen SufaceHolder gibt ( also der SurfaceHolder null ist). Hier sind die Methoden onSurfaceDestroyed(), onSurfaceCreated(), onSurfaceChanged(), onDestroy(), onCreate(), usw. entsprechend zu beachten.

Aber wo kommt jetzt endlich der Code zum Zeichnen hin?

Eine mögliche (aber nicht besonders sinnvolle) Stelle wäre die onSurfaceCreated() Methode:

@Override
		public void onSurfaceCreated(SurfaceHolder arg0) {

			Canvas canvas = getSurfaceHolder().lockCanvas();

			// Zeichne einen Kreis
			canvas.drawCircle(200, 200, 10, color);

			getSurfaceHolder().unlockCanvasAndPost(canvas);
		}

Dies hat zur Folge, dass ein Kreis gezeichnet wird sobald der SurfaceHolder erzeugt wird, also einmal und dann nie wieder.

Was wir aber für bewegte Animationen benötigen ist eine Möglichkeit das Zeichnen regelmäßig anzustoßen. Das Cube Beispiel aus dem SDK verwendet hierfür eine recht elegante Lösung unter Verwendung eines Handlers, welcher sich selbst immer wieder auf die “Queue” schmeißt. Ich möchte hier nicht weiter auf die Implementierung der Engine eingehen und auf das Cube Beispiel verweisen, da dies sonst den Rahmen des Artikels sprengen würde. Ich bin mir aber sicher, dass man mit dem hier gelernten Wissen das Cube Beispiel relativ gut verstehen kann. (Falls jemand Interesse an einem ausführlicheren Artikel zur Implementierung eines Wallpapers hat, kann er/sie gerne einen Kommentar hinterlassen.)

3. Die “Einstellungen”-Activity

Dies ist eine ganz normale Activity, welche dem Nutzer ermöglichen soll das Wallpaper zu personalisieren. Vorstellbar wären z.B. Farbe, Geschwindigkeit und diverse Effekte des Wallpapers. Hierfür sollte man wie im Cube Beispiel auf SharedPreferences zurückgreifen um die Einstellungen auch beim Zeichnen mitzubekommen. Zusammengefasst: Diese SettingsActivity lässt den Nutzer die SharedPreferences editieren, welche wiederum in der Engine beim Zeichnen berücksichtigt werden.

Hier sollte man beachten, dass diese Activity normalerweise nicht im AppMenü von Android auftauchen soll. Daher sollte man das Manifest (siehe Punkt 5) entsprechend anpassen. Diese App wird gestartet wenn der Nutzer in der LWP-Liste neben dem LWP auf Einstellungen klickt.

4. LWP lwp_config.xml

Diese XML Datei dient dazu, zu konfigurieren wie das LWP im LWP-Menü aufgelistet wird. Sie muss sich im Verzeichnis res/xml befinden, wenn dieses Verzeichnis nicht existiert muss man eins erstellen. Eine typische Konfiguration würde folgende Werte enthalten:

• android:thumbnail = mini Vorschaubild in der LWP-Liste
• android:description = kurze Beschreibung für die LWP-Liste
• android:settingsactivity = Packagepfad zu der Settings-Activity

5. Das Manifest

Im Folgenden wird der WallpaperService und die SettingsActivity eingerichtet.
Man beachte, dass kein Menüeintrag erstellt wird.

Ich hoffe ich konnte einen Überblick und ein Grundverständnis über die Erstellung eines Android Live Wallpapers bieten. Ich habe bewusst ein paar Details vorenthalten und versucht mich auf das Wesentliche zu konzentrieren. Bei offenen Fragen einfach einen Kommentar hinterlassen.

Um ein bisschen Abhilfe zu verschaffen erkläre ich  hier zwei Methoden, mit Hilfe derer Android-Clients REST-Server ansprechen und JSON-Format übertragen, bzw. verarbeiten können.

Zuerst der Theoretische Teil: REST steht für Representional State Transfer und wurde im Jahr 2000 von Roy Fielding vorgestellt. Wie der Name bereits sagt, können Stadien transferiert werden, sprich auf solche zugegriffen werden. Oder andersrum: Ein REST-konformer Server kennt keinen Zustand. Rest baut auf dem HTTP-Protokol auf und verwendet (mindestens) vier der Basiskomponenten:

GET für Datenanfragen,

POST für das Ablegen von Daten,

DELETE für das Löschen von Daten und

PUT für das Updaten von Daten.

Internetnutzer sollten zumindest mit GET-Befehlen vertraut sein. Internetseiten, die Daten anfordern, übertragen, wenn sie so programmiert wurden, wie es von den HTTP-Schaffern (zu denen auch Fielding gehört) gedacht war, in der URL Parameter. Diese Parameter werden mit einem ? eingeleitet (z.B. http://www.andforge.net/?m=201001).

Als Übertragungsformat hat sich auf mobilen Endgeräten aufgrund des geringen Datenoverheads die JavaScript Object Notation, kur JSON, als passend erwiesen. JSON stellt Objekte Beispielsweise wie folgt dar:

{
  "Name" : "Mustermann",
  "Vorname"      : "Max",
  "Adresse"       :
  {
    "Strasse"        : "Musterstrasse",
    "Nummer"     : "123",
    "PLZ"  : "98765",
    "Ort"   : "Musterstadt
  }
}

Das Format ist also durchaus noch lesbar, aber in seinen Zusatzzeichen, die eine Interpretierbarkeit ermöglichen, sehr sparsam. Dies ist für die eventuell schwachen Verbindungen, die es auf Mobiltelefonen geben kann, hilfreich.

Nach dieser kurzen Einführung wenden wir uns DER Frage zu: Wie geht das in Android?

HTTP GET

Zunächst einmal wird ein REST-konformer Webservice, der im JSON-Format antwortet benötigt. Hat man diesen, kann es losgehen:

public class Xxx{

//Bezeichnung der Klasse:

private final String TAG="Xxx";

public void getJSONObject(String url)
{

HttpClient httpClient = new DefaultHttpClient();
HttpGet httpGet = new HttpGet(url);
HttpResponse response;

try {
response = httpClient.execute(httpGet);

// TODO: HTTP-Status (z.B. 404) in eigener Anwendung verarbeiten.

Log.i(TAG,response.getStatusLine().toString());

HttpEntity entity = response.getEntity();

if (entity != null) {

InputStream instream = entity.getContent();
BufferedReader reader = new BufferedReader(new InputStreamReader(instream));
StringBuilder sb = new StringBuilder();

String line = null;
while ((line = reader.readLine()) != null)
sb.append(line + "n");

String result=sb.toString();

Log.i(TAG,result);

instream.close()

JSONObject json=new JSONObject(result);

JSONArray nameArray=json.names();
JSONArray valArray=json.toJSONArray(nameArray);

for(int i=0;i<valArray.length();i++)
{
//TODO: Inhalte der Arrays verarbeiten.
}
}
catch (ClientProtocolException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (JSONException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (Exception e){
e.printStackTrace();
}finally{
httpGet.abort();
}
}

Zuerst erzeugen wir einen HTTPCLient. Dann wird ein HTTPGet-Objekt erzeugt. Diesem Objekt wird eine URL mitgegeben, die bereits alle Parameter der Anfrage enthält. Da Wir eine Antwort vom Server erwarten, erzeugen wir zudem ein HTTPResponse-Objekt. Nun führen wir den HTTPGet-Request aus und schreiben die Antwort in unser HTTPResponse-Objekt.

Nun machen wir uns an die angehängten Daten. Diese befinden sich in der HTTPEntity der Antwort. Wir lesen sie mit Hilfe eines buffered readers und eines stringbuffers (aus Performancegründen) aus und erzeugen aus dem so generierten String ein JSONObjekt, welches alle übertragenen Daten enthält, sofern sie im JSON-Format waren. Mit diesen Daten kann nun gearbeitet werden.

So einfach lassen sich Daten mittels REST und JSON in Android abfragen.

HTTP POST

Die nächste Frage, die sich aufdrängt: Daten abfragen funktioniert, aber wie ist das mit den drei anderen Dingern?

Fangen wir mit einer Methode zum Abschicken eines HTTP POST- Objektes an:

public void postJSONObject(String url, JSONObject data, String objectName)
{
HttpPost postMethod = new HttpPost(url);

try {
HttpParams params = new BasicHttpParams();
params.setParameter(objectName, data.toString());

postMethod.setParams(params);
httpClient.execute(postMethod);
Log.i(TAG, "Post request, data: " + params.toString());

} catch (ClientProtocolException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();

} finally {
postMethod.abort();
}
}

Wie zuvor wird der Methode eine Ziel-URL übergeben. Des Weiteren wird ein JSONObject mit den zu übertragenden Daten und die Bezeichnung der Daten (z.B. “User”) übergeben. Da wir einem HTTPPost nicht einfach so ein JSONObject anhängen können, wandeln wir dieses zuerst in HTTP-Parameter um und hängen diese dann an.  Nun führen wir den POST aus und alles ist gut (hoffentlich). Natürlich sollten an dieser Stelle noch eventuelle Fehlercodes oder -Meldungen abgefangen werden, dies kann analog zur ersten Methode geschehen, wobei Fehlermeldungen natürlich für jeden Server individuell behandelt werden müssen (üblicherweise gillt: wenn ein JSON-Objekt mit “error:” beginnt, ist was schief gelaufen).

HTTP DELETE und HTTP PUT

DELETE und PUT können so wie POST implementiert werden, nur dass der Objekttyp von postMethod in HTTPDelete, bzw. HTTPPut, geändert wird.

Et voilà: So schnell geht’s und schon fangen die Server an zu flüstern, mehr als das, sie hören sogar zu =)

[ad#google_article_mo]

Der Trick hierbei ist, dass das Bild  auf den momentanen Blickwinkel des Benutzers angepasst wird.  Das im Video gezeigte User-Interface ist leider nicht echt und soll nur zeigen wie so etwas theoretisch aussehen könnte.

Das Prinzip ist jedoch seit langem bekannt und wurde bereits durch folgendes Video sehr berühmt. Es zeigt eine beeindruckende Umsetzung dieser optischen Täuschung für die Nintendo Spielekonsole Wii.

3D Hologramm Effekt für Android

Theoretisch ist es technisch möglich solch einen Effekt auch für Android Geräte zu entwickeln. Ich habe mir daher ein paar Gedanken gemacht und möchte nun beschreiben wie man das ganze auf einem Android Gerät realisieren könnte. Für diesen Effekt ist es essentiell, dass die Positionen von Betrachter und Gerät relativ zueinander ermittelt werden können. Daher habe ich die verschiendenen Bewegungsmöglichkeiten im Raum  in die folgende Fälle unterteilt und sie isoliert betrachtet.

1. Handy kann nur kippen

Zunächst möchte ich davon ausgehen, dass sich der Kopf des Benutzers und das Android Gerät fest im Raum befinden. Sie können sich in keinerlei Richtung Bewegen. Das Gerät kann aber in alle möglichen Richtungen gekippt werden.

Möchte man nun unter diesen Umständen einen 3D Effekt erzeugen, muss man nur die Lage des Gerätes anhand der Beschleunigungssensoren (welche momentan so gut wie alle Android Geräte besitzen) ermitteln. Mit den Daten kann man dann das Bild auf dem Gerät so anpassen, dass man einen wunderbaren Effekt erzielt. Wenn man sich hierbei ein Auge zuhält wirkt der Effekt noch besser, da dann jegliches Gefühl für “Tiefenwahrnehmung” verschwindet .

2. Handy kann sich nur Horizontal/Vertikal bewegen

Jetzt kommt der etwas kompliziertere Fall drann. Ich möchte jetzt annehmen, dass sich das Gerät auf einer Art Schiene im Raum nach oben, unten, links und rechts bewegen kann. Es kann sich jedoch in keine Richtung drehen/kippen. Bei diesen Bewegungsabläufen helfen uns die Beschleunigungssensoren leider nicht mehr weiter, da wir die Position des Gerätes relativ zur Position der betrachtenden Augen benötigen. Dies könnte man mit einer Front-Kamera, wie es heutzutage viele Video-Telefonie-Taugliche Geräte haben realisieren. Die Kamera müsste dann anhand eines Augen-Erkennungs-Algorithmusses die Position der Augen des Benutzers ermitteln. Es gibt bereits einige solcher Algorithmen, welche oft in  Digitalkameras eingesetzt werden.

3. Handy kann sich nur auf der Z-Achse bewegen

Dieser Fall ist ähnlich zu lösen wie der vorherige. Hier wird angenommen, dass sich das Gerät nur nach vorne und hinten bewegen kann. Es kann wieder nicht gekippt werden. Wenn sich das Handy exakt auf einer Linie vor dem Betrachter befindet hat diese Bewegung keine Auswirkung auf den Bildschirminhalt.

Befindet sich das Handy, jedoch leicht versetzt neben dem Betrachter und bewegt sich dann auf der Z-Achse muss dies auch erfasst werden um den Effekt  möglichst realistisch wirken zu lassen. Auch hierfür benötigt man einen Augen-Erkennungs-Algorithmus. Um die Länge der Strecke zwischen Handy und Betrachter zu ermitteln muss man diesmal den Abstand zwischen den beiden Augen messen. Liegen die Augen relativ nah zusammen ist der Betrachter etwas weiter entfernt. Vergrößert sich dann der Abstand zwischen den Augen bewegt sich der Betrachter auf das Android Gerät zu. Das selbe funktionier natürlich auch umgekehrt.

Die Mischung machts!

Kombiniert man nun alle drei Fälle kann man mit den ermittelten Daten einen wunderbaren 3D Hologramm Effekte auf Android Geräten erzeugen, welcher den Effekt aus dem TATMobile Video noch weit übertreffen könnte. Ich bin mir sicher, dass in den nächsten Monaten noch viele coole Experimente auf diesem Gebiet passieren werden.

[ad#google_article_mo_2]

4. Das Ultimative 3D Erlebnis !!!

Das Android Gerät besitzt einen weiteren nicht zu unterschätzenden Sensor. Den Kompass! Mit diesem liese sich der 3D Effekt um einen besonders coolen Aspekt erweitern. Man könnte die auf dem Bildschrim dargestellten “Pseudo-3D-Objekte” von allen möglichen Seiten betrachten.

Das folgende Video zeigt diesen Effekt sehr schön. Es ist eine Kombination aus den Punkten 1 und 4. Man beachte, dass sich weder Kamera noch das Gerät von der Stelle bewegen.

Der 3D Hologramm Effekt ist machbar!

Mit den hier vorgestellten technischen Möglichkeiten sind solche Effekte theoretisch nur eine Frage der richtigen Implementierung. Es müssen nämlich aller der 4 Fälle berücksichtigt werden um die perfekte Illusion zu erzeugen. Ein Android Phone mit Front-Kamera wäre natürlich auch recht hilfreich .

Ich übersehe unter Umständen ein paar Aspekte oder es geht noch einfacher als ich es hier beschrieben habe. Daher würde ich mich über Feedback und weitere Ideen zu diesem Thema sehr freuen.

Nachtrag:
Ich habe gerade ein weiteres Video zu diesem Thema entdeckt. Wieder ist es eine iPhone App, welche offensichtlich mit Kompass und den Beschleunigungssensoren arbeitet. Wie bei der “Katze” von oben wirkt der Effekt nur solange wie der Betrachter seine relative Position zum Gerät nicht verändert.

Für weiter Infos und einen Screenshot einfach den Blogeintrag  http://www.andforge.net/?p=1552 lesen.

Feedback ist natürlich wie immer erwünscht.

Oft wird über Geschäftsmodelle geredet oder geschrieben, dabei aber oft auf Ideen zur Ertragserzielung, sprich ein Ertragsmodell, reduziert. Tatsächlich beinhaltet es aber deutlich mehr als nur dieses.
[ad#google_image_middle_jo]
Was ist also ein Geschäftsmodell tatsächlich?

Wie der Name schon sagt das Modell eines Geschäfts. Es hängt also eng mit der Definition von “Geschäft” zusammen. Da diese unterschiedlich ausgelegt wird, ist auch die Definition von ” Geschäftsmodell” nicht eindeutig. Auf jeden Fall ist das letztendliche Ziel eines Unternehmens die Generierung von Wert, sei es in ökonomischer, sozialer oder anderer Form.

Nachfolgende Punkte sind die Kernpunkte eines Businessplans, die ein Geschäft gut beschreiben können und vor einer Neugründung auf jeden Fall definiert werden sollten.

1. Die Marketingstrategie: Eine Marketingstrategie umfasst mindestens vier Punkte, die klassischen “vier P” des Marketing: Produkt (product), Preis (price), Werbung (publicity) und Distributionspolitik (place). Darüber hinaus gibt es weitere mögliche p’s, wie beispielsweise Menschen (people).
2. Das Ertragsmodell: Wie oben beschrieben der Weg der Ertragserzielung.
3. Markt: Die Antwort auf die Frage: Welcher Märkt oder welche Märkte, bzw. welches Marktsegment oder welche Marktsegmente können mit dem vertriebenen Produkt oder den vertriebenen Produkten penetriert werden?[ad#google_article_jo]
4. Wettbewerber: Eine Übersicht der vorhandenen direkten und indirekten Wettbewerber auf dem oder den existierenden Markt oder Märkten, bzw. Marktsegment oder -Segmenten.

Darüber hinaus

1. Das Nutzenversprechen: Um Absatz zu erzielen, müssen Kunden, seien es Endkunden oder Kooperationspartner, einen Nutzen aus dem Unternehmen ziehen können. Dies sollte definiert werden, und zwar in der
2. Architektur der Wertschöpfung: Beantwortet die Frage: Welche Leistungen werden wo, also auf welchem Markt, wie, sprich: mit welchem Produkt, angeboten?

In den weiteren Folgen dieser Serie werden nun die einzelnen oben genannten Punkte abgehandelt, beginnend mit Punkt eins: Marketing.