I can write at design time a setting bundle, but I need to make its content appear according to certain condition
can I do that , if yes any sample code, and where to put this code
Best regards
You can't dynamically create a Settings.bundle and write it out while your application is running on the iPhone. It needs to be included in the code signed application package.
What you can do, though, is customize your already created bundle's content & UI based on those certain conditions. E.G. different preferences load different strings or graphics.
Related
The problem is the following.
The title for button FindName is wrong and it should be Search, another thing is that window title is misspelled: "DisplayUsrEmail"
I don't have the source code of the application.
My main requirement is to write the small application that will modify the current application and fix above problems.
I have to write the new app using Swift.
What I did:
1) It is quite simple to change the title of the button without coding. (FindName -> Search) I changed it in the Info.plist file.
2) It is also easy to change the app title (Executable file) in the Info.plist, but in my case, it doesn't change the window's title "DisplayUsrEmail"
3) I opened the apps unix executable file in the hex editor (used https://hexed.it/) and found there the title "DisplayUsrEmail". But the app crashes when I add the byte with symbol 'e'. ("DisplayUsrEmail" -> "DisplayUserEmail") I can just change the title with the same characters count, but it doesn't resolve my problem.
So, is it possible to write the new app that will modify the current one? If yes, what is the workflow?
The app is compiled through xcode and is a known fact that it is not possible to retrieve the source code from the compiled application.
To answer your question: no, it's not possible.
I don't think that this is at all possible. When an app is built, it's also codesigned to prevent any changes to it. If any changes are made, macOS can't (or refuses to) open the app. This is a security feature that prevents people from modifying applications to bypass security measures, licensing, etc. in the app. Since you've modified the app, you are seeing this security feature in action in the form of the app crashing when you attempt to launch it.
That being said, it MIGHT be possible to modify the UI elements only without affecting the executable. In the app's resources folder, there should be a file with a ".nib" extension. This is the compiled user interface which is where the incorrect spelling of the window and button are. If you modify this file ONLY, the UI elements might be correct when you launch the app again. It's also possible that this nib file is part of the codesigned bundle and modifying it will cause a crash, just as if you'd modified the executable.
I am using code first api for UI Automation.
I want to check whether file is downloaded or not on button click.
I am able to find the button and click is working fine .
i dont know how to check the file is downloaded or not.
I am new to this technology. sorry if it is a basic question.
Thanks in advance.
Coded UI does not have any built-in facility for checking that a download completed and actually downloaded a file. However, Coded UI tests can use the full facilities of the language they are written in plus the .Net libraries.
In the Coded UI test method, at the place where you expect the download to have been completed, add some code to check the properties of the file that should have been created. For example: its existence, its creation and/or modification date and time, its size. Use the normal file IO operations to perform the checks. Microsoft provide details on How to do basic file I/O in Visual C#.
After performing the checks it may be beneficial to delete the file, to reduce wasted disc space.
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.
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.
i have an app that i have to localize. I am already localizing the nibs and some texts, i just have a doubt.
I need to pull a plist from the bundle which contains some texts, for the other languages i would have other plists. How can i accomplish the loading of them in a nice simple way.
My initial though is to have a text.plist , text-sp.plist , text-fr.plist and retrieving the current language then if language == english grab the text.plist, if language == spanish grab text-sp.plist and so on.
Is there a better way to do this?
I'd rather somehow make the .plist localizable and do something similar to what i do with texts using NSLocalizedString, but i am not sure how to use it in this case.
Sorry, just found the solution.
Just right click the .plist file and add new localizations like any other file. Then the OS handles which one to load according to the current locale settings.
I had to clean my targets in order for the changes to take effect, thats why i initially thought this was not working.