Beiträge von Ben

die Frage war ja, woher den windows key nehmen

würde ich definitiv optional implementieren. Eine App wo registrierung erforderlich für die nutzung ist, ist ein nogo. Dieser verteilte Kühlschranks hat zwar potential, aber du solltest da eher was programmieren, das man sowas z.b. auch in seiner eigenen cloud laufen lassen kann.
zusammengefasst:
1. Cloud funktion optional, primär konzentration auf das lokale smartphone
2. Nur wenn der user explizit möchte, registriert er sich und nutzt deinen "cloud dienst"
3. optional kann der user sich auch, in seiner owncloud oder einer mysql seiner wahl in seinem netzwerk, die daten ablegen lassen, statt in deiner cloud.

Zudem würde ich nie mit sowas wie "login weitergeben" argumentieren, gefährlich, animiere nutzer doch nicht dazu ihre passwörter anderen personen zu geben, auch nicht wenn diese zur familie gehören. Da solltest du eher ein prinzip implementieren, mit dem man seine Kühlschränke sharen kann. "Useraccount1" nutzt dann den selben virtuellen Kühlschrank wie "Useraccount2".

Es geht nicht nur um Passwörter (auch wenn du sie nicht siehst, du könntest sie sehen und du solltest dem user die möglichkeit geben zu entscheiden ob er dieses risiko eingeht oder nicht), es geht auch um seine Daten. Das umfasst was er isst, wann er einkauft, wieviel er einkauft, wer alles zur familie gehört und viele sachen mehr. Glaub mir, so eine "cloud" (ich hasse den begriff, eigentlich ist es nichts anderes als eine server-infrastruktur) erfasst weitaus mehr persönliche Daten als man denkt, bzw. kann dies tun. Du musst dem user entscheiden lassen, welche daten er in die cloud schiebt und welche nicht.

Na dann brauchst du ja keine hilfe mehr xD
Ab auf github und verlinken, vielleicht gibts paar pull requests von mir.

Andere Frage, warum muss man sich registrieren um die app nutzen zu können?

aah jetzt weiß ich was du meinst, sry kannte den begriff drawer noch nicht.
von dem sprach ich aber nicht.

mh bin nicht sicher ob so ein itemkontextmenü mir gefällt, ungewohnt in android. vielleicht eher beim klick in die activity zum editieren wechseln und darin dann die anderen optionen mit anzeigen.

1 + 2: danke das du die kritik annimmst und zumindest drüber nachdenkst
3: du hast vollkommen recht, aus nutzer sicht sind sowenig klicks wie möglich sehr gut. Aber so wenig klicks wie möglich resultiert eben in sehr vollgepackten layouts. Besser passt, soviel klicks wie nötig. Ein Kompromiss zwischen layouting (stichwort goldener schnitt) und so wenig klicks wie möglich, ist daher das optimum.
4: ja das ist mit viel suchaufwand verbunden, gerade im bereich nahrung lässt sich nicht sehr viel finden. Aber gibt inzwischen hier und da große iconsets. Das von Bootstrap ist in der kleinen variante sogar kostenlos.

nein sowas gibt es mMn nicht in java und ich wüsste auch nicht warum es sowas geben sollte. Wieso soll man das erstellen eines Konstruktors verbieten? Wenn man ihn auf private hat und angst hat das er doch, von einer anderen Person, in der klasse irgendwo instanziiert wird, muss man dann nicht auch angst haben, dass diese andere Person das verbot plötzlich aufhebt?

ruhig mit den jungen pferden, du hast doch erst gestern gefragt
es klingt recht interessant, dein projekt. Ist halt immer die Frage inwieweit man sowas aufziehen will.
Großes projekt oder nur so für einen selber, open source oder closed source?

theoretisch könntest du aus dem relativelayout auch ein zweites linearlayout machen. Bei deiner kleinen anwendung sollte das mMn aber nicht ins gewicht fallen.

Also laut dem Code den du gestern noch reineditiert hast, hast du das ja schon gesetzt.
Setz mal vor das if eine Logcat ausgabe um zu sehen ob der callback überhaupt aufgerufen wird. wenn ja, ist was mit deinen if bedingungen falsch

Toolbar:
Pack sie auch dort rein und hau dafür die rezeptvorschläge aus dem startbildschirm raus, dann hast du genug platz und es wirkt nicht so vollgepackt wie jetzt

Buttons:
sorry ich weiß immernoch nicht was du meinst und weiß auch nicht was ein drawer ist
Oder meinst du nicht das letzte sondern das grüne bild? Dann meinst du sicher das Menu was aufgeht wenn du in der toolbar auf die drei punkte clickst oder? Das ist vollkommen ok, das der popup dann aber mitten im Bild aufgeht ist nicht ok. Der sollte direkt unter der toolbar am rechten rand aufgehen.

Styling:
Versteh das nicht falsch, ich hab das aussehen deiner app nicht mit der seite verglichen. So schlimm ist sie nun wirklich nicht xD. Viel eher war das ein Hinweis meinerseits, das der ersteller dieser seite, diese auch schön findet, obwohl sie es definitiv nicht ist. Es muss auch nicht alles genau im Material Design sein, aber es soll doch leute ansprechen und nicht abschrecken und das erreicht man durch einfache stilistische mittel:
1. Du willst verschiedene Farben nutzen, warum nutzt du nicht die vielen verschiedenen Farben die eben Material definiert? Da gibts auch Rot Grün Geld etc. nimm doch diese anstatt selber welche zu definieren.
2. Verwende nicht überall verschiedene schriftarten, im Logo auf der hauptseite ok, aber der rest in der app sollte die android eigenen schriftarten enthalten.
3. Auf der Hauptseite könntest du Platz sparen indem du nur 4 icons statt 6 machst, die "irgendwas hinzufügen" könntest du in den jeweiligen activities machen, wo du einfach im contextmenu (die drei punkte in der toolbar) einen jeweils einen eintrag machst "hinzufügen".
4. Sehr hilfreich ist es, ein einladendes look and feel zu kreieren. Dabei hilft auch wenn die Icons die du verwendest vom stil her gleich sind. Also am Besten sollten sie alle aus dem gleichen Iconset stammen.

Du musst in die Liste einen adapter setzen und genau das ist der CursorAdapter der die Daten aus der Datenbank ausliest.

Hi

setOnEditorActionListener und der OnEditorActionListener() sollte dir helfen

ach das linearlayout ist der container für den editText, ok dann passt das

naja du könntest einen loginmechanismus programmieren, bevor jemand mit der app daten abfragen will, muss er sich registrieren. Stichwort sessionmanagement.

wozu das relativelayout außenrum?

Hi :)!

mh also die layouts sehen mir seeehr sehr unvorteilhaft aus. Zu realisieren geht das natürlich mit Fragmenten, aber dieses Konzept ist meiner meinung nach nicht umsetzenswert.

Hi

als erstes solltest du den quellcode mal in einen quellcode container packen, mit wir ihn besser lesen können. Diesen Container findest du im Foreneditor in der Symbolleiste unter den rechten vier symbolen.

Dann wäre es gut wenn du den Text nochmal überarbeitest, so dass wir die Frage genau verstehen und dir eine passende antwort gegeben können.

VG.
Ben

Es nimmt den platz ein den es eben braucht, wenn du als textgröße sp benutzt, sollte es auch in einem gewissen Rahmen skalieren, das geht natürlich aber nicht unendlich. Irgendwann ist der Bildschirm halt nicht mehr breit genug, dann könntest du noch eine scrollview benutzen die vertikal scrollen kann. Die einzige andere Möglichkeit wäre dann, deinen text zu verringern und somit das layout zu verkleinern.

was gefällt dir von beidem besser? ObjectiveC oder Swift?

Ok, das sagt mir, das du also auf eine Restschnittstelle zugreifst. Annotationen wie @GET bedeuten doch aber eigentlich, dass du hier eine REST schnittstelle zur verfügung stellst, oder? Ich kenne REST nur so das auf der Serverseite über @GET und @POST mit Ressourcen interagiert wird und auf einem client dann nur noch über die URIS auf die Schnittstelle zugegriffen wird.

nach erneutem genauen analysieren hab ich dein eigentliches problem erkannt. Du setzt den Fullscreen mode im quelltext. Ich weiß nicht ob das so funktioniert. Die saubere lösung ist es, den fullscreenmode im xml theme zu integrieren, den du für deine app als apptheme setzt.