Beiträge von Marco Feltmann

Zitat von ChampS

Mit Swift wollte ich mich eh längst mal auseinandersetzen

Masochist.
Ernsthaft, Swift ist durchaus sehr lustig. Produktiv aber eher unbrauchbar.

Zitat von Xyt4n

Also einfache Frage, gibt es eine funktionstüchtige IDE mit der man Apps für Android und iOS entwickeln kann auf einem Windows PC?

Einfache Antwort: Nein.

Zitat von ChampS

Die Frage ist aber, welchen Inhalt könnte man schaffen, der nicht schon zur genüge im Internet einsehbar ist?

• Communityprojekte
• spezifische Webinare

Beispielsweise ließe sich eine Foren-App als Communityprojekt realisieren.
Dazu dann ein paar (Video)Tutorials um alle auf den gleichen Stand zu bekommen, am Projekt teilzunehmen.
In Webinaren dann beispielsweise Kanban vs. Scrum vs. Scrumban vs. Waterfall durchspielen, Projektplanungen durchführen, gemeinsam an Problemlösungen basteln, Erweiterbarkeit und Abstraktion von Codes aufzeigen oder Ähnliches.

Also was wirklich Realitätsbezogenes. Wie man eine ListView befüllt sieht man überall.
Wie man an die Daten über REST API nach vorherigem OAuth kommt nicht.
Wie man einen Batchmodus für die Zeit ohne Internet implementiert nicht.
Wie man eine halbwegs sinnvolle Cachingimplementierung für die Zeit ohne Internet auf die Füße gestellt bekommt nicht.
Wie man unterschiedliche Inhalte in der App je nach 'Sicherheitsstufe' darstellt nicht.

Natürlich spielt da der Faktor Zeit eine nicht ganz unwesentliche Rolle.
Man braucht Zeit sich da ein Projekt zu überlegen.
Man braucht Zeit sich zu einem vereinbarten Termin im virtuellen Konferenzraum zu treffen.
Man braucht Zeit sich mit den Themata zu beschäftigen.

Vor gut 18 Jahren nach der Schule hätte ich die Zeit dafür gehabt.
Nun habe ich sie nicht mehr – naja, und meine Prioritäten liegen natürlich bei iOS.

Na dann, leg los.

Docking Stations wird es für Android so nicht geben, da jedes Gerät seinen Anschluss woanders haben kann.

Ladekabel an Mehrfachsteckdose, strombetriebener USB Hub mit passenden USB Kabeln oder (kostenintensive) Powerbanks beispielsweise von Anker – wobei letztere nur entweder aufgeladen werden oder Geräte laden können – gleichzeitig laden und entladen klappt nicht, daher vermutlich keine Option.

Zitat von § 2 Deutschen Sommerzeitverordnung

Die Umstellung von der Normal- auf die Sommerzeit findet am letzten Sonntag im März um 1 Uhr UTC, also in der mitteleuropäischen Zeitzone von 2 Uhr MEZ auf 3 Uhr MESZ, statt.
Die Umstellung von der Sommer- auf die Normalzeit findet am letzten Sonntag im Oktober um 1 Uhr UTC, also in der mitteleuropäischen Zeitzone von 3 Uhr MESZ auf 2 Uhr MEZ, statt.

Das lässt sich ziemlich genau berechnen.
Eventuell ein Verbesserungsanreiz für OPunktSchmidt.

Natürlich muss bei einer Gesetzesänderung auch der Algorithmus angepasst werden.

Zitat von Le0Dev

Die Frage nach den Kosten eines Entwicklers ist schwer zu beantworten, ich würde aber mindestens mit 35€/Stunde/Entwickler rechnen, eher sogar mehr

Wenn Du einen mit 35€/Stunde/Entwickler kennst, ich hab da einige Projektideen, zu deren Umsetzung ich einfach nicht komme.
Der normale Satz ist eher das Dreifache. Davon ab werden heute eher Projektpreise verhandelt denn Stundensätze.

Mit funktionierendem Akku und Windows 10 Unterstützung wirkt das eher unrealistisch.
eBay Kleinanzeigen vielleicht.

Ansonsten ein bisschen mehr Geld in die Hand nehmen und im Anschluss auf Garantie hoffen: Aldi (Süd) hat wohl demnächst eins für unter 250€ im Angebot.
http://www.heise.de/newsticker…ei-Aldi-Sued-2789459.html

Wie stellt Dein Livetracking denn dar, wenn der Nutzer fünf Minuten an der Fußgängerampel steht, sich also 30x die Position nicht verändert* hat?
Im Übrigen glaube ich nicht, dass das Tracking so dermaßen live sein muss, dass Du das alle 10 Sekunden hoch laden musst. Vielleicht läuft eh Spotify mit und Du kannst das bequem über das System regeln lassen.
Vielleicht hat der Nutzer auch 'mobile Daten' deaktiviert, um sein Kontingent zu schonen. (Mache ich beispielsweise regelmäßig)
Dann ist einerseits Deine Livetracking Idee hinfällig und andererseits kommen die Daten dann nie auf einen Server.

Eigentlich sind das zwei Paar Schuhe.

Der GPS Chip schaltet sich ein und sucht eine Position, sobald $irgendwer das in Auftrag gibt.
Aus Gründen der Energieersparnis bleibt das Ding dann ein paar Sekunden an, weil 30 Sekunden laufen lassen weniger Strom kostet als 6x anschmeißen, 5 Sekunden lang den fix abwarten und wieder killen.

Wenn im Hintergrund irgendwer (Facebook oder Google Maps zum Beispiel) kontinuierlich die Postion abfragt, dann schaltet sich der Chip auch nicht ab.
Dein Service wird da auch gar nicht lange starten und warten müssen, er bekommt einfach die Infos.

Warum das Abfragen alle 10 Sekunden sein muss verstehe ich nicht.
Zu Fuß kommst Du in 10 Sekunden nicht annähernd so weit wie mit dem Rad (16,7m bei 6km/h vs 55,6 m bei 20km/h) und 10 Sekunden im Auto sind streckentechnisch ein Witz gegenüber 10 Sekunden im Flugzeug (166,7m bei 60km/h vs. 1,67km bei 600km/h).

Die Aussagekraft der Messung ist also meiner Meinung nach sehr fragwürdig.

Lass lieber den Service im Hintergrund laufen und Dich über Änderungen informieren.
Nutze statt permanent selbst zu fragen lieber public void requestLocationUpdates (long minTime, float minDistance, Criteria criteria, PendingIntent intent)
Setz die Zeit meinetwegen auf 10 Sekunden oder so. Setz die Distanz aber auch auf was Sinnvolles, 25 Meter oder so.
Dann bekommst Du wenigstens keine Info, wenn der Nutzer an der Ampel oder im Stau steht, vor dem Schaufenster hängen geblieben ist oder weil das GPS mal ein bisschen in der Gegend herumgependelt hat.
Es sei denn, Du willst das. Dann setz die Distanz auf 0 und Du bekommst weiterhin stumpf alle 10 Sekunden Deine Info.

Hinzu kommt, dass sich das GPS dann auch nicht abschaltet, da Du ja freudig die Informationen abfragst.

PS: Den Punkt 'und hochlädt' halte ich allerdings für fragwürdig. Alle 10 Sekunden Daten auf irgend einen Server pumpen würde ich ja sein lassen.
Lieber sammeln und das Betriebssystem dann bei der nächsten vom User initiierten Netzwerkaktivität (Mails lesen, WhatsApp tippen, Facebook gucken) die gesammelten Daten hochpumpen lassen. Denn alle 10 Sekunden Datenverbindung aufbauen, ein paar Byte rüberschicken und dann wieder abbauen kostet wirklich viel Energie.

Zitat von sredomat

Jetzt gehen wir davon aus das Konzept ist perfekt durchgeplant und fertig

Das ist es garantiert nicht.
Ein Konzept ist niemals fertig und schon gar nicht perfekt durchgeplant. Geplante Konzepte scheitern immer an der Realität, beispielsweise Einschränkungen in der API oder seitens der Richtlinien für Apps.

Zitat von sredomat

und ich habe jede einzelne Seite der APP auf Photoshop so designed wie sie im Endstadium aussehen soll und übertrage dies nun an die Apple-Entwickler.

Auch das hast Du garantiert nicht.
Du hast vielleicht die Unterscheidung Smartphone/Tablet oder versionsspezifische Eigenheiten vergessen bzw. kanntest sie nicht.

Zu Deinen Fragen:
1) Ich denke nicht, dass Du das wissen willst. Die Antwort wäre auch: Zu wenig. Rechne mal damit, dass Du 120€ bis 150€ pro Stunde zahlen darfst – der Entwickler bekommt höchstens ein Prozent davon ab.
2) Kommt drauf an. Ideal ein iOS, ein Android, ein Web/Frontend und ein Datenbank/Backend Entwickler. Vielleicht findest Du aber auch den ein oder anderen Allrounder.
3) Bei den genannten vier Entwicklern klingt Dein Anforderungsprofil (und Du hast garantiert die Hälfte nicht erwähnt) nach ca. 4 Wochen.

Datenbanken und Normalisierung sind Themen diverser Vorlesungen.
Es ist nahezu unmöglich, Dir das in einem Foreneintrag zu erklären.

Vielleicht hilft Dir das Video:

Oder der Lars Vogel:
http://www.vogella.com/tutorials/AndroidSQLite/article.html

Du legst Dir die TextViews als Membervariablen Deiner Activity/Deines Fragments an und änderst dann über die entsprechenden Setter die Inhalte.

//…
TextView moneyLabel = (TextView)findViewById(R.id.playermoney);
//.. 
  if( moneyLabel != NULL ) {
  
    moneyLabel.setText("pleite");
  }
//…

Ein paar Gedanken dazu.

1) Hybride Apps halte ich vor dem Hintergrund der zeitkritischen Notwendigkeit einer Kommunikations–App für ungeeignet.
Zwar lässt sich mittlerweile mit WebRTC viel machen, nativ läuft aber signifikant performanter bei der Audio– und Videokommunikation.

2) Ein Startup ist immer mit Risiken verbunden. Ihr zahlt ja nicht nur die x Wochen, die am Programm gearbeitet wird. Ihr zahlt auch für das KnowHow, dass die Umsetzung keine x*x Wochen dauert.

3) Den Ansatz einer Prototypentwicklung halte ich für falsch. Der Dienstleister sollte schon die App selbst entwickeln und das Prototyping entweder mit übernehmen oder halt nach euren Vorgaben 'final' entwickeln. Dazu solltet ihr das Prototyping zumindest des UI schon erledigt haben.

4) Meidet Unternehmen, die starre Regularien fordern. Ihr könnt es euch nicht leisten, die App genau nach dem von euch definierten Lastenheft erstellen zu lassen um festzustelen, dass die Bedienung nicht intuitiv ist.
Setzt auf agile Methoden und verlangt die Herausgabe von Iterationsschritten in Form von entsprechend lauffähigen Apps.
So könnt ihr regulierend eingreifen, wenn ihr fest stellt, dass ihr da auf eine Wand zu rast. Und es kostet weniger, zwei Wochen lang in die falsche Richtung zu rennen und dann nachzuarbeiten anstatt die komplette App drei mal erstellen zu lassen.
Ja, ihr zahlt dann pro Iterationsschritt und nicht pro Projekt. Erfahrungsgemäß scheitern die erstellten Lastenhefte jedoch im ersten Lauf immer.

5) Gewöhnt euch im Vorfeld an den Gedanken, dass das Geld kostet. Der Zahnarzt will sein Geld auch sofort und nicht erst, wenn ihr nachweislich über drei Wochen schmerzfrei seid. Die Schneiderin möchte ebenfalls sofort bezahlt werden und nicht erst, wenn man nachweislich Star des Abends war und 500 Likes auf Facebook für das Outfit bekommen hat. Auf Beteiligung wird wohl niemand eingehen.

6) Ihr könntet das Ganze so 'myhammer' mäßig ausschreiben. [0]
Achtet aber auf jeden Fall auf die Qualität der Anbieter. Weiterhin bekommt ihr da einen Überblick, was da an Kosten auf euch zukommen kann.

0) http://app-entwickler-verzeichnis.de

Preferences sind nicht einfach so leer.
Du machst also Fehler beim Auslesen. Falscher Preference Name, falscher Key, irgendwie sowas.

Weiterhin solltest Du lieber einen Hash statt des Kennworts ablegen.

Dein Absturz schließlich dürfte daran liegen, dass Du ungefähr sowas machst:

Log.e("Tag", object );

Wenn jetzt object == NULL ist, kann das mitunter schief gehen.
Du solltest also mal schauen, was Du in der DialogAdminDisabled.java in Zeile 66 geschrieben hast und was davon NULL sein könnte.

Also zunächst mal halte ich mich nicht für ausreichend qualifiziert, als 'Datensicherheitsfredi' aktiv zu werden. Deshalb gibt es nur ein paar allgemeine Tipps und Hinweise und im Anschluss zwei Vorträge zum Thema 'Apps' und 'Sicherheit' einer Mac–/iOS Entwicklerkonferenz im letzten Jahr.

Du möchtest auf jeden Fall diese intimen persönlichen Daten auf Deinem Server lagern. Wolltest Du dies nicht, würdest Du sie nicht erheben.
Insofern musst Du das Auslesen um jeden Preis verhindern.

Dazu gehört:

• Übertragung nur über eine gesicherte Verbindung
  Du musst Deiner App garantieren, dass sie mit dem richtigen Server spricht. Hier sind Zertifikate immer eine gute Sache. Allerdings stellt das einen gewissen Mehraufwand dar, da Zertifikate oftmals bezahlt aber immer gepflegt/erneuert werden müssen.
• Ansteuerung der Datenbank nur über eine fest definierte API
  Direkter Zugriff auf Datenbankservern ist so ziemlich das Bequemste, das man einem Angreifer anbieten kann. Entsprechende beispielsweise in PHP mit Symfony2 realisierte API Skripte reduzieren das Risiko wahllos Daten ausspähen zu können enorm.
• Bei API Zugriffen ständig auch Berechtigungen des Anfragenden prüfen
  Statt einfach drauf los auszuliefern sicherstellen, dass bei der Anzeige persönlicher Daten einer Person auch wirklich diese Person die Daten einsehen möchte.
• Code Injections vermeiden
  Das API muss natürlich dämliche Eingaben wie 'name=jo"); SELECT * FROM user; echo("Ha' abfangen.
• API Funktionen an entsprechend eingeschränkte Datenbanknutzer knüpfen
  Funktionen, die nur lesend auf die Datenbank zu greifen, sollte man über einen Datenbanknutzer ausführen zu lassen, der ausschließlich Leserechte in diesen Tabellen hat. Hier kann man schon viel Sicherheit schaffen, wenn es beispielsweise für die personenbezogenen Daten einen eigenen Datenbanknutzer gibt, der nur dort lesen kann und auch der Einzige ist, der dort lesen kann.

Natürlich muss man immer sicherstellen, dass der Schutz, den man zugestehen will, der Nutzbarkeit der App nicht entgegensteht.
Beispielsweise könnte man Copy'n'Paste für die Adressdaten unterbinden. Dient die App aber zur Vernetzung der Anwender, wäre ein Export ins Adressbuch ein wünschenswertes Feature und alles Andere würde zu sehr blockieren.

Vorträge (spezialisiert auf iOS)
Applied Crypto Hardening mit TLS

Sicher ganz einfach

Ich denke, ich habe die Aufgabenstellung verstanden.

Wie Du einen theoretisch kreisrunden Pfad senkrecht schneiden möchtest, weiß ich allerdings nicht.
Vielleicht könnte es klappen, wenn Du einen Pfadrand so skalierst, dass er durch den Punkt 3 geht. Dann hättest Du den Punkt auf dem Pfad und kannst an Hand des Dreisatzes die entsprechenden Punkte auf den anderen Pfadrändern berechnen.

Vermutlich hast Du vergessen Dein APK zu signieren.

Anleitung gibt es von Google selbst:
https://developer.android.com/…blishing/app-signing.html

Moin!

Ich verstehe zwar nicht, was ein Raspberry Pi mit Android zu tun hat, aber: Wenn Du Fragen hast, frag gern nach.

Moin!