Eigenes Cocoa Touch Framework in kleine Teile aufteilen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Eigenes Cocoa Touch Framework in kleine Teile aufteilen

    Hi! Hat hier jemand Erfahrung mit Cocoa Touch Frameworks (Also die Dinger, die man mit @import importieren kann?)

    Ich habe davon nämlich eins. Das Problem: Es wird mir langsam zu groß! Es besteht quasi aus 2 großen Teilen (machen je ca. 40% des Frameworks aus) und zu insgesamt ca. 20% aus 5 kleinen Teilen.
    Das Framework wird in mehreren Projekten verwendet, die 2 großen Teile werden immer benötigt. Aber die kleinen halt nicht - daher würde ich mir gerne den Speicherplatz sparen und die kleinen Teile einfach garnicht mit compilern.

    Klar, ich könnte einfach mehrere Frameworks bauen lassen, die aufeinander aufbauen - und halt nur die benötigten importieren. Aber gibt es auch noch andere Möglichkeiten? Kann man nicht evtl. irgendwo ein paar flags setzen, um für jedes Projekt die benötigten Teile auszuwählen?

    Wer kennt sich da aus?

    Danke schonmal!
    T.
  • Hallo,

    Du kannst einfach unterschiedliche Targets anlegen und bestimmen was dann dadrin landet.

    Speicherplatz?
    Also ich habe nen Mamut-Framework entwickelt mit unzähligen Klassen und Kategorien.
    Von Speicher kann da aber keine Rede sein.

    Spielt doch keine Rolle, ob das 200 oder 300kb groß ist.
    Oder hast Du Millionen Downloads über Deinen eigenen Server, so dass Du das bezahlen mußt? ;)

    Viele Grüße
  • Ein wichtiger Vorteil eines Collection- oder Tableviews ist die Möglichkeit, mit einer relativ geringen View-Anzahl eine extrem große Anzahl von Objekten darzustellen. Wenn die Anzahl der Objekte relativ klein ist, braucht man es nicht unbedingt auf einen Collectionview umzusetzen. Andererseits kann die Implementierung eines Collectionview-Layouts durchaus einfacher sein, als die entsprechenden Restriktionen anzulegen.

    Falscher Thread. :D
    „Meine Komplikation hatte eine Komplikation.“

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von macmoonshine ()

  • Ja, es geht mir wirklich um die paar kB! Klar, bei Bildern muss man auch sehen, wo man bleibt, aber ich finde, wenn ich etwas optimieren kann, dann sollte ich das auch tun, ein paar kB machen natürlich kaum einen Unterschied, aber Verschwendung finde ich nie gut, das mag einem natürlich kleinlich vorkommen, aber ich bin grundsätzlich kein Freund von unnötig aufgeblähter Software.
  • little_pixel schrieb:

    Ersetze lieber die Bildchen mit @2x durch Vektor-PDF.
    Da lässt sich bei vielen etwas gewinnen.

    Unter iOS? Da gewinnt man höchstens etwas Zeit, die man für das manuelle Speichern der Bilder gespart hat. ;)
    martiancraft.com/blog/2014/09/…bout-pdf-support-in-xcode

    Der Sinn der dynamischen Frameworks liegt darin, dass Du die komplette Funktionalität dieser Komponenten zur Laufzeit zur Verfügung hast. (Dynamische Erzeugung von Objekten, die Du in Deinem Code nicht explizit eingebunden hast, funktioniert.)
    Der Sinn der statischen Bibliothek liegt darin, dass die benötigten Komponenten zur Compilezeit in Dein Paket gestopft werden. (Dynamische Erzeugung von Objekten, die Du in Deinem Code nicht explizit eingebunden hast, führt zum Absturz.)

    Was Du möchtest widerspricht also dem Grundgedanken des Frameworks.
    Ergo: Nimm eine static library.

    Ein Framework ist doch eigentlich auch nur dann sinnvoll, wenn es mehrere Anwendungen autark verwenden sollen.
    So dass Du beispielsweise nicht in jeder Deiner App eine eigene AFNetworking Library einbinden musst, sondern jede App auf ein AFNetworking Framework zugreift.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Also ich gehöre auch zu den Perfektionisten und alles muss super sein.

    Aber wegen ein paar kb mir einen derartigen Stress zu machen.
    Ne, dann wäre ich plemplem… ;)

    Zumal das ja nur eine Momentane Entscheidung ist.
    Situationsbezogen.

    Morgen brauchst Du in nem anderen Projekt eine Klasse, die sich nicht mehr im Framework befindet.

    Dann geht wieder der Stress los…

    Außerdem habe ich Dir oben einen Tipp gegeben, wie Du beim Build Dein Pridukt leichter machen kannst.

    Hast Du das in der Vergangenheit gemacht?
    Wenn nein, dann mache sowas statt Dich selbst zu limitieren und Stress zu bereiten.

    Viele Grüße
  • tedalligator5 schrieb:

    [...] aber Verschwendung finde ich nie gut, das mag einem natürlich kleinlich vorkommen, aber ich bin grundsätzlich kein Freund von unnötig aufgeblähter Software.

    Das ehrt Dich, aber dann wünsche ich Dir, dass Deine App nie Design-Vorschläge der Marketing-Abteilung ertragen muss... :D

    Wie sonst lässt es sich erklären, dass kaum noch eine iOS-App unter 20-30 MB liegt? Natürlich mag dies an diversen hochauflösenden Launch-Images liegen, die man in der App-Entwicklung mit schnelleren Startzeiten hätte weg optimieren können, oder gar an eingebundenen Frameworks. Aber ganz im Ernst: Wenn sich Apps in der UI der Standard-Elemente bedienten und nicht alles fancy-bunt sein müsste, könnten viele Apps deutlich kleiner sein.

    Auf der anderen Seite, wen stört's: Der Speicher meines iPhones wird eher von App-Daten denn von den Applikationen selber belegt und Bandbreite für Download / Update sollten heutzutage kein Thema mehr sein. Das waren noch (nicht lang vergangene) Zeiten, als Horden von Programmierern 2 Bytes für das Jahrtausend / - hundert sparten ... mit fragwürdigem Erfolg. Wobei, eine Arbeitsplatzsicherung war es schon, zumindest kurzzeitig.

    Sorry für's Abschweifen, genug philosophiert, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • gritsch schrieb:

    Marco Feltmann schrieb:

    Unter iOS? Da gewinnt man höchstens etwas Zeit, die man für das manuelle Speichern der Bilder gespart hat.
    martiancraft.com/blog/2014/09/…bout-pdf-support-in-xcode


    das ist aber auch schwachsinn was der da macht.
    wenn du schon ein pdf hast, dann dieses NICHT in ein asset packen sondern direkt als resource ins projekt (und damit ins app-bundle) legen.

    Und wie verwendest du dieses pdf dann in einem UIImageView?
  • Michael schrieb:

    gritsch schrieb:

    Marco Feltmann schrieb:

    Unter iOS? Da gewinnt man höchstens etwas Zeit, die man für das manuelle Speichern der Bilder gespart hat.
    martiancraft.com/blog/2014/09/…bout-pdf-support-in-xcode


    das ist aber auch schwachsinn was der da macht.
    wenn du schon ein pdf hast, dann dieses NICHT in ein asset packen sondern direkt als resource ins projekt (und damit ins app-bundle) legen.

    Und wie verwendest du dieses pdf dann in einem UIImageView?


    UIImage unsterstützt doch pdf!?
  • Sorry für's Abschweifen, genug philosophiert, Mattes

    Nö, hast absolut Recht und da es dem TE um Speicher geht auch passend…

    Meine Geschichte dazu:

    Ich habe einer meiner Anwendungen vom Designer komplett neu gestalten lassen.
    Früher hatten wir alles mit PNG-Grafiken und die gesamte Anwendung war ca. 3MB.

    Als ich das erste Test-Release erstellt hatte war die Anwendung auf einmal 15MB groß.
    Ich konnte das kaum glauben und schnell war klar, dass es an den Bildchen lag.

    Dem Designer habe ich geschrieben, dass er das optimieren soll und er meinte nur "wem juckt das, wie groß das ist".
    Tja, und da hat er Recht. Seit Apple die Anwendungen hostet interessiert das offensichtlich niemanden mehr.

    Aber mich schon, da ich die Anwendung selbst anbiete und ne Porno-Leitung habe für die ich jedes GB bezahlen muss.
    Das hat er dann auch verstanden und nach dem er sich mal um die richtigen Export-Einstellungen gekümmert hat war die gesamte Anwendung nur noch 2,9MB groß.
    Über 12MB kleiner bei gleicher Qualität. Das ist ganz schön viel bei den tausenden Downloads, die ich habe.

    Was ich damit sagen will:
    Seit dem Apple die Infrastruktur bietet interessiert sich niemand mehr für "Optimierungen" in Sachen Speicherbedarf…

    Viele Grüße
  • little_pixel schrieb:

    Sorry für's Abschweifen, genug philosophiert, Mattes

    Nö, hast absolut Recht und da es dem TE um Speicher geht auch passend…

    Meine Geschichte dazu:

    Ich habe einer meiner Anwendungen vom Designer komplett neu gestalten lassen.
    Früher hatten wir alles mit PNG-Grafiken und die gesamte Anwendung war ca. 3MB.

    Als ich das erste Test-Release erstellt hatte war die Anwendung auf einmal 15MB groß.
    Ich konnte das kaum glauben und schnell war klar, dass es an den Bildchen lag.

    Dem Designer habe ich geschrieben, dass er das optimieren soll und er meinte nur "wem juckt das, wie groß das ist".
    Tja, und da hat er Recht. Seit Apple die Anwendungen hostet interessiert das offensichtlich niemanden mehr.

    Aber mich schon, da ich die Anwendung selbst anbiete und ne Porno-Leitung habe für die ich jedes GB bezahlen muss.
    Das hat er dann auch verstanden und nach dem er sich mal um die richtigen Export-Einstellungen gekümmert hat war die gesamte Anwendung nur noch 2,9MB groß.
    Über 12MB kleiner bei gleicher Qualität. Das ist ganz schön viel bei den tausenden Downloads, die ich habe.

    Was ich damit sagen will:
    Seit dem Apple die Infrastruktur bietet interessiert sich niemand mehr für "Optimierungen" in Sachen Speicherbedarf…

    Viele Grüße



    wieviele milliarden male wird das denn reuntergeladen dass es ins geld geht?
    eventuell bist du beim falschn anbieter!

    ja, ich versuch die dinger auch immer möglichst klein zu halten.

    pngs kannst du automatisch optimieren lassen (zb mit ImageOptim.app).