Android Sets/Erweiterungen definieren

[JustAnotherName]

Guten Abend Community,

ich stehe grade etwas auf dem Schlauch, vielleicht könnt Ihr mir ja bei meinem Problem helfen:

Und zwar möchte ich einige Sets statisch festlegen, und während der Laufzeit auf die Daten zugreifen.

Mein Ansatz sieht derzeit so aus:

public class Set {
        private String name;
        private Item[] items;

        public Set(String name, Item[] items) {
            this.name = name;
            this.items = items;
        }

        public String getName() {
            return name;
        }

        public Item[] getItems() {
            return this.items;
        }

        public static class Item {
            private String name;

            public Item(String name) {
                this.name = name;
            }

            public String getName() {
                return name;
            }
        }

        public static Set[] all = new Set[]{
                new Set(
                        "Test set 1",
                        new Item[]{
                                new Item("Test item 1.1"),
                                new Item("Test item 1.2"),
                                new Item("Test item 1.3"),
                                new Item("Test item 1.4"),
                                new Item("Test item 1.5")
                        }
                ),
                new Set(
                        "Test set 2",
                        new Item[]{
                                new Item("Test item 2.1"),
                                new Item("Test item 2.2"),
                                new Item("Test item 2.3"),
                                new Item("Test item 2.4"),
                                new Item("Test item 2.5")
                        }
                )
        };
    }

An und für sich funktioniert er auch ohne Probleme, dennoch kann ich mir noch vorstellen das es so "richtig" ist. 

Weiß evtl. jemand wie man es "richtig" lösen würde und mag mir da unter die Arme greifen?

Mir würden auch ein paar Begriffe, die ich googeln kann, reichen.

Stehe grade echt auf dem Schlauch und wüsste nicht einmal, nach was ich genau suchen sollte.

 

Vielen Dank im Voraus! 

[Whiz-zarD]

Da liegst du richtig, dass man es so nicht macht.

Ich schreibe hier gerade vom Smartphone aus, deswegen kann ich gerade kein Beispiel schreiben, aber das was zu suchst, nennt sich unter Java HashMap. Kannst ja mal danach suchen. 

[JustAnotherName]

Guten Morgen Whiz-zarD,

danke für deine Antwort, aber ich glaube eine HashMap an und für sich ist hier auch nicht das richtige.

Am liebsten hätte ich eine Ressource, die ich als statische "Datenbank" verwenden kann:

<?xml version="1.0" encoding="utf-8"?>
<sets>
	<set name="set1">
		<item
			name="item1" 
			value="test"/>
  		...
	</set>
	<set name="set2">
		<item
			name="item2" 
			value="test"/>
  		...
	</set>
  	...
</sets>

 

[Whiz-zarD]

Dann musst du mal erklären, was du unter "Set" verstehst und was du damit machen möchtest.
Natürlich kannst du dir auch eine XML-Datei schreiben und diese dann Parsen. Unter Java kannst du auch JAXB oder XMLBeans verwenden. Das sind Frameworks, mit der du XML-Elemente direkt mit Java-Klassen binden kannst. Das hat den Vorteil, dass du die Eigenschaften anpassen kannst, ohne gleich neu kompilieren zu müssen. Ansonsten musst du das Parsen selbst übernehmen; z.B. mit SAX. So oder so entspräche dies eher dem Open-Closed-Prinzip.

[JustAnotherName]

Mit Set meinte ich ein "Set" was der User zur Erweiterung der App kaufen kann.

Da die Sets statisch sind, würde mir eine hardcoded Implementation reichen. Jedoch gehe ich davon aus, dass es eine schönere Möglichkeit gibt, um solche "Sets" abspeichern zu können.

[Whiz-zarD]

Naja, es werden doch mal weitere Erweiterungen hinzukommen, oder nicht?
Daher ist so etwas ja nicht unbedingt statisch und sollte auch nicht in der App hinterlegt werden, sondern sollte über eine REST-Schnittstelle abgerufen werden. Ansonsten müsste man bei jeder neuen Erweiterung eine neue Version der App ausliefern. Ich könnte mir da sowas wie OData vorstellen.

 

[JustAnotherName]

Bei der App sind die Sets jedoch vom Anfang an begrenz. Bzw. Falls doch mal irgendwann ein weiteres Set dazu kommen sollte, ist es einfacher eine neue App Version heraus zu bringen als eine Datenbank anzulegen, download Server bereits zu stellen und eine Schnittstelle zu implementieren. Es stand anfangs im Raum die Setverwaltung serverseitig zu lösen, haben uns aber dagegen entschieden, würde einfach keinen Sinn machen.

Bearbeitet 11. Oktober 2016 von Anluin

[Whiz-zarD]

Welche Gründe sprechen denn dagegen? Der initiale Aufwand? Wurde auch berücksichtigt, dass die App sich nicht alleine deployed? Jedes Mal eine neue App in den Store laden, wenn eine Erweiterung hinzugefügt wurde, halte ich für nicht zielführend. Schon mal davon ausgehen muss, dass nicht jeder die aktuelle App-Version besitzt und somit nicht alle Erweiterungen sieht.

Eine REST-Schnittstelle zu implementieren ist jetzt auch nicht die Welt. Man braucht jetzt auch keine Datenbank aufsetzen. Eine XML- oder SQLite-Datei würde auch schon reichen. Alternativ lädt man nur die XML-Datei runter. Ein Apache-Server ist binnen wenigen Minuten aufgesetzt und ein HTTP-Request ist mittels Java auch ein Ein-Zeiler. Über die Zeit gesehen ist dieser Aufwand geringer, als immer eine neue App in den Store zu laden.

[JustAnotherName]

Es über einen Server abzuwickeln ist bei dieser App einfach nicht sinnvoll. Wie bereits gesagt sind die Sets bereits festgelegt und werden sich nicht (bzw. seltener als ein App-Update bezüglich Änderungen am Layout & Co.) ändern.

Wie ein Serverabgleich der Sets über einen Server abgewickelt werden würde weiß ich, es ist in diesem Fall jedoch weder sinnvoll noch 

[arlegermi]

Also ist deine Frage grundsätzlich, wie du statische Daten mit deiner App ausliefern sollst? Klar kannst du das in Code machen. Ich weiß jetzt nicht, wie relevant in deinem Fall i18n ist, aber falls es auch nur irgendwie denkbar ist, würde ich so was eher als Resource-Datei anlegen. Dann kann das auch jemand bearbeiten, der keine Ahnung von Java hat, bzw. kein Android Studio / Eclipse installiert hat.

Die Resource-Datei liest du dann bei App-Start ein und kannst genauso darauf zugreifen wie im Augenblick auf deine statischen Daten.

[JustAnotherName]

Mit Ressourcendatei meinst Du z. B. eine XML-Datei, die ich dann aber selber parsen muss?

Wenn ja ist dabei ein Problem, und zwar das ich in einer eigenen XmlDatei keine Verweise auf andere Ressourcen (aller @string/app_name) hinterlegen kann bzw. ich diese Funktionalität selber implementieren müsste.

Oder gibt es einen vom Android Studio unterstützen Ressourcentype mit den ich komplexe Typen speichern kann?

<list name="sets">
    <set name="set1" title="@string/title_set2">
        <item name="item1" img="@drawable/img_item1" title="@string/title_item1"/>
        <item name="item2" img="@drawable/img_item2" title="@string/title_item2"/>
        <item name="item3" img="@drawable/img_item3" title="@string/title_item3"/>
        <item name="item4" img="@drawable/img_item4" title="@string/title_item4"/>
    </set>
    <set name="set2" title="@string/title_set2">
        <item name="item1" img="@drawable/img_item1" title="@string/title_item1"/>
        <item name="item2" img="@drawable/img_item2" title="@string/title_item2"/>
    </set>
</list>

 

[Whiz-zarD]

Was meinst du mit komplex?

Bild-dateien könntest du mit Base64 kodieren und als ein CDATA-abschnitt in die XML-datei packen. Wenn die Texte mehrsprachig sein müssen, kannst du auch nur einen identifier in die XML-datei packen und dann für die Sprachen eine Ressourcen-datei anlegen oder du legst für jede Sprache ein eigenes Element in der XML-datei an.

Wenn ich mich noch recht erinnere, dann müsste in Android auch SQLite integriert sein. Vielleicht ist das ein Stück eleganter.

Es gibt hier nun mal keine einfache klicki-bunti-lösung. Da muss man dann selbst ran.

[JustAnotherName]

vor 56 Minuten schrieb Whiz-zarD:

Es gibt hier nun mal keine einfache klicki-bunti-lösung. Da muss man dann selbst ran.

Okay, mehr wollte ich nicht wissen.

Danke