I am figuring out which one is more storage friendly when it comes to getting some icons which are not available in the flutter icons module.
So, there are two ways to do it
Get your icons as assets, store in the app, and then use it wherever you want
Get a package, in my case, font_awesome_flutter, which practically has the required icons. And then use the icon via this package after importing it.
I am wondering which one should I prefer, first one or second?
Note: I am not bothered about the process, but I care about the space it takes in the app, which eventually affects the app's size.
Related
I am trying to make an extension based app, where you can download extensions to the app to add features/widgets. Could I somehow run an uncompiled dart file downloaded from a server that stores the .dart files?
download(file.dart)
compile(file.dart)
storeInPersistentDirectory()
if (dartFile.exists) {
ClassFromDownloadedFile.sayHello()
}
The aim is to decrease the app size by storing all of the data related to an extension in the dart file, (classes, json and images in the form of a string...). Users might want to download features, while some don’t need them, in which case they shouldn’t need to download a large app with many features that they will never use, so the initial app size remains small.
Thank you for anyone who knows anything relating to this in advance!
No, it is not possible. You can download a 'resource' such as image/video/mp3 etc. You can even download the dart file but can't compile and execute.
there is a concept in dart and other modern languages called reflection(mirroring).
Reflection allows us to examine and modify the structure and behavior
of a program at runtime.
search about it and check the below links for more information.
dart document
Understanding Reflection and Annotations in Dart
I recommend searching for RMI too.
I am trying to get into mobile app development and chose to make a song book app in flutter as my first exercise project. In this app I would like to display the song texts/lyrics as formatted text with paragraphs indentations etc.
My first plan was to store the songs in a (SQLite) database and put in the formatted texts as html code.
However, I noticed that flutter does not really have a built-in html interpreter. I tried some 3rd party plugins but they already failed with simple tables. Now I am considering to use WebView. However, I guess I would then have to store all the song texts as individual htm(l) files.
Does anyone have a recommendation or does someone see an easier way to achieve what I want to do?
Without knowing what the exactly went wrong with your initial approach, my inclination is that you are on the right track.
sqfLite should work perfectly well for this https://pub.dev/packages/sqflite, then you could use a package like flutter_html https://pub.dev/packages/flutter_html to render the html strings or just use RichText class if you want more styling options https://api.flutter.dev/flutter/widgets/RichText-class.html.
I have a Default.png which includes a version number on it. Every time I update my app, I have to change it both in the lite and full version's default.png and default#2x.png. Hassle, no?
I'm pretty sure I've been going about this the wrong way. What should I do instead? (I would like to show a version number on launch, not just nix it altogether.)
Compile-Time Image Compositing
If your logo doesn't need to change other than the version number, then you can use your graphics library of choice at compile-time to refactor the png. Pseudo code below:
Pseudo-Code:
UpdateLogo(String logoName, String version)
{
WidgetImage MyLogo(logoName + ".png");
MyLogo.DrawText(800, 650, version);
MyLogo.Write(logoName + "Final.png");
}
UpdateLogo("Logo.png", "Version 1.0.0");
Compile that program and keep it around as a custom build tool. Then whenever you need to build your application you can compile Logo.png into LogoFinal.png. If you need help using XCode or other tools to generate image files I suggest you search for image manipulation tools separately from "dynamic versioning".
Ideally your version string will use constants defined in an easily-editable table or controlled by your build system. At the very least it will save you from opening up Photoshop every time you need to build your app.
For Display in a Running Application
You should be using a font to draw the version number on top of the logo. Then you can just include a resource file that is text-based and can be easily updated by automated tools for each build.
Sources
Can you create custom build rules for XCode based on file type?
Apple's Human Interface Guidelines say that the Default.png shouldn't be used as a splash screen; it should represent all of the UI controls the application will show, but without any localizable text or content. (Think of how the the built-in apps like iPod and Contacts behave.)
If you're doing it for a client and they demand it, you can always use the "But the app store might reject it for violating their terms!" argument.
Of course, this doesn't apply if you're not submitting to the Store or if you just don't care. :)
A technical add-on for the people posting above: make sure that any png compositing you're adding to the build process runs before pngcrush executes, so that you're not replacing an optimized image with a script-generated (and likely unoptimized) one. You may also run into weird issues if you try doing it after pngcrush runs (it not displaying), anyway.
When releasing to the application store someone wrote in an offhand comment that you need to avoid embedding your images into the executable.
How do you do that?
I've seen code in various books that suggests encoding images as C byte array constants in the source code, and I can say that that's definitely a bad idea for reasons ranging from inefficient pixel formats to unsalvageable memory. That would qualify as "in the executable file" in a way that bundle resources don't, since bundle resources are packaged alongside the executable rather than within it.
I am not sure if I get you correctly, but maybe he meant accidentally adding image files to the Compile Sources category in your build target? This usually does not happen with images, but i have seen it happening with js files.
Perhaps they meant that you should only include images in the bundle that are essential.
The bundle is essentially read-only so you cannot remove an image from the device that is in the bundle. Therefore placing lots of example images that you expect a user to remove/not want is not a good idea because when the user deletes the images from inside your app no space on the device will be reclaimed.
Of course it is fine to place images in the bundle just make sure that they are required and are not taking up unnecessary space that the user cannot reclaim.
I'm currently in the process of adapting an existing iOS app into what will be a family of very similar apps (each app instance will probably map to a different country/region).
I'm planning on having a different build target for each of these instances, and the only differences between them should be:
Images (probably just the splashscreen and icons)
Localizations
String variables: base URL for remote services, application ID, support e-mails, etc (possibly half a dozen of such variables)
The code itself should be the same on all apps.
What I'd like to know is what you consider to be best practices for managing a family of applications like this.
Regarding images and localizations (or resources in general), it should simply be a matter of adding/removing the appropriate files from the target (and I guess I can even use the same name for images, in different directories).
The main thing I'm not sure about are the other configuration variables.
I've heard / thought of a few options:
Using preprocessor macros and a main configuration header file with the different URLs, IDs, etc
Loading them from a plist (or similar configuration file) whenever the application launches, and having one such file per target
Creating an empty .sqlite file (this app already uses Core Data) and populating it with the default configuration variables, and having one such file per target
I think the first option is the fastest to get out of hand once I have a few instances of this app, plus I have to recompile every time I change one of these settings.
The third option I'm also not sure about, because I'll be adding entities to my database which don't feel like they belong there, plus it kind of feels like overkill for what will probably be 5-10 settings. I'm also not sure about how to add new settings on updates.
So I'm leaning more towards the second option.
Thoughts? Any alternatives to these?
UPDATE #1:
Regarding the second option, there is also a drawback that those strings (ids, URLs, etc) will be slightly more exposed (i.e. if someone was to open the app and look through the plist) than if they were in the source code. Not that this is that big of a problem, but it's just something to consider.
Update #2:
How about using the app's info.plist directly and storing it there? (thus having an info.plist for each target configuration) Even though originally I was thinking of having a separate plist, and having a "configuration singleton" which would load everything from there on startup, I think it may be simpler to simply have it in the info.plist and then reading it via [[[NSBundle mainBundle] infoDictionary] objectForKey:#"com.example.mykey1"].
I would take the preprocessor option. You can put all your preprocessor in one file/method and it will not be too messy. Like oefe said, change the .sqlite is overkill. And with the multiple plist, you will find yourself dragging things around and doing a lot of error prone actions.
However, I would not make a lot of apps. I would just make one app, let the user select his city at launch. You could also add in-app purchases to let the user add more cities when he wants to.
Your app will be easier to maintain : do you want to upload, change description and screenshots for 10+ apps at each update? I find this painful to do with 1 app...
You will not spam the AppStore : having 10+ more apps in the AppStore with the exact same purpose is ridiculous... That's exactly why Apple made in-app purchases, to avoid that situation.
You will have to find different icon for each of your city : your icon is one of the most important aspect when selling your app on the AppStore. You want it to be as polished as possible. Apple won't allow multiple apps to have the same icon and differentiate icon by putting a label on it is not a good option.
I ended up going for the plist, but instead of creating a new one I used the info.plist file for this, thus no need for extra files per target, as I already needed to have a separate info.plist for each one. I simply load them directly from the bundle with:
[[[NSBundle mainBundle] infoDictionary] objectForKey:#"com.example.mykey1"]
I also used preprocessor (with flags set on the target settings) for a couple of things, but that was mostly for when I wanted to disable/remove completely some parts of the app (e.g. to make sure I got everything I commented out enumeration values and even includes in a couple of places).
I think it's relatively clean and I can easily replicate this for future builds without too much of a mess.
Given that the variation is per country/region, and these variables are strings, why don't you simply treat them as localizable strings, thus reducing the problem to one already solved?
Otherwise, I would go for the plist. Sqlite seems to be an overkill, and is not source-control friendly. And conditional compilation will get messy fast.