I have a project in App Inventor that uses the TinyDB. In this project, I added an extension I couldn't delete and didn't want.
To solve this problem, I made a copy of the app, downloaded the copy as an aia, unzipped the project and fixed the problem, and then zipped it back up.
Then I deleted the copy on AI so I could upload the changed version. Everything went according to plan, and now I have an app with the problem and a fixed project under a different name.
My question is if I delete the problem app and save-as the copy under the original name, will the tags in the TinyDB still be there or will they be in a separate database that I can no longer access?
I tested this question with a simple app I made. Here are the steps I followed, you can skip to the bottom if you want the conclusion:
Methods:
Create a project
Drag in a list view component, two textboxes, a tinyDB, and a button. It doesn't have to look pretty, it just has to be functional
Go to blocks
Add in the blocks below
Build the apk and install it on your device. Store at least 1 tag.
Go back to AI. In the project, click Project>save as... and leave the project name at the default.
Delete the original
In the copy, click Projects>save as... and set the name to the original name you used.
Build the apk and install it on the device. Do not uninstall the first app you installed.
Confirm that the entries you added are still in the app.
Conclusion:
When testing this, I found that the data in the tinyDB would persist from the other version of the app. I think this was because the project name was the same, I was signing the app with the same digital signature, and the tinyDB namespace was the same.
Therefore, it is safe to change the name of the app and then change it back without losing the data on a user's device.
Further steps:
I would also like to test if this works when downloading the aia, unzipping it, and then zipping it back up and uploading it. I think that would yield the same result, but I have yet to test it.
Related
I have this needs.
I developed an app and I want to duplicate it. I can copy and paste the project but if I do this 10 times can be a problem. The problem is, if I found a bug in the 10th duplicate, I have to review all other projects and I don't want to do this.
There is a clean way to solve this problem?
In other words, I have only one big code. The differences between the apps that I have to deploy are:
Launcher icon
Domain of the HTTP request
Package name
Splash Screen
App name
Some integers inside the app
Some assets
In Android, I do this with gradle, in particular, with the flavors. How I can do the same with Swift?
Create a single project with multiple targets. Each target would have a different info.plist and whatever other changes you need, but shared source.
I would do this with Git:
In your origin repository, prepare your project with placeholders:
Try to make a file where you define constants for the domain, the integers you mentioned etc. That file you could call Constants.swift.
Put all assets you need to change in one .xcassets. (a different one than the assets that will stay the same) For example the Icon. You can already add the image-sets you want to have in your apps, but leave them empty (or alternatively add placeholder images)
Write a placeholder for the app name and package name
create a default splash screen (I guess you mean the launch screen). This could either be empty or if you want it to be similar in all apps, prepare it a bit so you don't have to change much for each app
When you have committed and pushed your main project, create forks for each of your apps. In the forks, you can change everything that you have prepared as placeholder.
If there is a but somewhere, fix it in the origin. Then you can merge the changes easily to each of your forks.
Here's my setup:
(1) Create a new project of type Framework.
Move all shared code - extensions, subclasses, image assets, even .xib files - into a this project. I created an App/Bundle ID ("com.company.framework") but I'm not sure if it is necessary for App Store submission. Also, checking off the "Allow app extension API only" will remove the warning you'll get.
For files like images or text files, create bundles and drag the bundles into the framework. I've found you can add new images/files through Xcode. To retrieve them, here's the code:
public func returnKernel(_ named:String) -> String {
let myBundle = Bundle.init(identifier: "com.company.framework")
let kernelPath = (myBundle?.path(forResource: "cikernels", ofType: "bundle"))! + "/" + named + ".cikernel"
do {
return try String(contentsOfFile: kernelPath)
}
catch let error as NSError {
return error.description
}
}
(2) Create a second project, this time for your specific app.
Let's say you called your framework "Kernel". All public declared code is available by adding:
import Kernel
Now, here's the best part (for me): you have two ways to work with this setup.
(3a) Drag your framework .xcodeproj into your app project.
PROS: You can (a) make changes to your framework source code and (b) build both at once.
CON: You can only have one app project open at once because Xcode detects that the framework project is open.
(3b) Drag the Kernel.framework project into your app project.
PRO: You can have all your apps open at once.
CONS: You will need to (a) make your framework source changes in it's project, and - I think - (b) manually update every app with the rebuilt framework.
I say "I think" because I use the former set up. It's a small price to pay to have one app open at a time. Typically if you are making a framework change it's for a single app.
FINAL NOTES:
Changes made to the framework while working in "app #1" will be picked up when you open "app #2".
I have separate Git repositories for (a) each app and (b) my framework, both locally and on GitHub. Works perfectly.
I have separate Bundle/App IDs (and versions) set up for (a) each app and (b) my framework in the Developer Portal.
Come App Store submission time, I archive the app and upload it. The framework comes along for the ride.
We developed an app for our client and it is now available in the app store. Lets call it the MAIN APP here.
Now the client wants a separate version of that app, without changing anything but just the name of the MAIN APP. Let's call it the ALT APP here.
The MAIN APP has two Xcode projects, one is the older one, the other is the latest, which is the one what I am working on with new features.
I uploaded the first version of the ALT APP before by changing the app name and bundle ID of the older project of the MAIN APP. So you can think of it that the older project of the MAIN APP is now the project of the ALT APP
Now I need to update the features of the ALT APP to the same as the MAIN APP.
One way to do this is to copy paste the source files of the MAIN APP and overwrite it to the source files of the ALT APP but I think this takes time.
The other way I thought of is to just change the app name and bundle ID of the latest project of the MAIN APP, upload the ALT APP and then later on change it back when I need to upload the MAIN APP
But I am afraid that if I kept on changing the bundle ID there will be build problems(although I haven't encountered any yet).
Is there any better way to do this? Thanks in advance!
Make One Project.
Go to Project setting -> Build Setting
Change
Current Project Version
As you want.
Duplicate your 'base' target as you want
Go to Target -> General -> Version
and Write $(CURRENT_PROJECT_VERSION)
Change bundle identifier.
Go to Target -> Info and find 'Bundle name' and change it. That will be your app name.
I wish you can solve your problem.
This sounds a lot like you need to look into branching in your source code repository. Git in particular is suited to pulling individual commits between branches. Thus allowing you to select changes to copy. Providing you are careful about what you are committing.
Ultimately it sounds like your project is going to end up being an old code based with patches and a new code base with new features. Perhaps your client is not clear enough about what they want. Keeping two version of an app current in the app store would be a headache. Far better to retire one and move with the new.
Xcode deleted my project and everything is gone. The only thing that I have is the app in my iPhone 6. So is there any way that I can retrieve the Xcode project of the app?
.. Update ..
i found all the files now i just need to reassemble them in a new project . but I don't know how .
Let's be clear: Xcode did not delete your project, you did, perhaps inadvertently. This does happen to most of us.
The answer is to recover from your remote Git repository or recover from Time Machine or another backup. If you do not have any backup this is your first warning that you need a backup strategy. Make this your last such warning by immediately, as in right now, creating a backup scheme, preferably two. Little is more important.
There are free remote Git repositories such as BitBucket. Setting up Time Machine is simple, just get an external disk, connect it and you will be prompted. Or use another backup scheme such as BackBlaze.
Without a backup you can recover the assets but not code from the ipa from your phone. If you are using the Asset Catalog that is not easy but can still be done.
Unfortunately,
There is no current way to un-archive an app. You must have the .xcodeproj file in order to make changes. The .ipa is useless in terms of editing or changing your app. And if there was a way to do so, it could and would be abused and many clones/copy's/fakes of popular apps will be published. The only accessible files are things in the Main Bundle which only include, .pngs, .jpg, .txt etc but no source code.
For testing purposes, I need to periodically deploy new builds of my iOS app to the device which has old data in its document folder. I'd like to be able to selectively update part of the data and control keep-new or keep-old behaviour for any files in the document folder.
Basically, the tooling support I want is to update only the data that changed when deploying to device. For example whatever in the dev-machine's Xcode project resource folder that are newer or different from their counterparts (files of the same names) on the device (by date, size, etc.) get transferred and their counterparts on the device get overwritten by those. Everything else is ignored.
An ideal scenario would be: When I hit BuildAndRun in Xcode, Xcode will figure out what data to transfer-and-overwrite-device-files and what not to based on some custom rules.
Is is possible to achieve this with Xcode?
UPDATE
I edited the above text to make it clear that I don't want to add app logic for data versioning. I want this to happen in my build-and-test pipeline (Xcode).
Normally, this is pretty simple. Everything that XCode sends goes in the resource bundle. If you update it on the device, you have to move it to the documents directory, as the resource bundle is write only.
Any resources that you might be updating on the device already need 'does document version exist' kind of logic, the only change you have is to maybe add some modification date stuff.
You do have the option in the run scheme to upload application data to the sandbox directory.
Here is a good starting point:-
http://developer.apple.com/library/mac/#recipes/xcode_help-devices_organizer/articles/copy_app_data_to_sandbox.html
In essence, you can download data from a device in the device manager and create an xcdata package. Edit this to contain just the stuff you want to upload.
You can then either upload this manually or specify it in the Edit Scheme dialog ( under options), so it gets uploaded every time you run the scheme.
Easiest way I see to do it is to encode a version number in the files, and the ones you need to update, you increase the version number on them in your code, so when it runs and encounters a file that has a lesser version number, it deletes or ignores it
I was successfully created a signed Blackberry app. I have ever deployed it and succeed. But i wonder why somehow, when now i debug it, the app won't run and said,
Error Starting `MyApplication`: Can't find entry point
During debugging, my project doesn't show any errors, packaging works well. As far as i remember, i do not perform any significant changes on my code nor on the project description and properties, before i got this error. Anyone here ever faced the same problem?
For your info, my project has only one main method and uses SMS listener thread inside UiApplication class. I get this error both on real device and simulator. I was trying to completely uninstall the app, but coincidentally it cannot be deleted because delete menu doesn't appear.
First of all, make sure that the main method is in a publicly accessible Class, and add a breakpoint to the first line inside the method, to check that the application isn't throwing an exception and dying on your. Also try putting the whole main method into a try/catch with exception logging to get a look at what might/might not be going on.
Secondly, it is possible that the device/simulator being used just needs the previous version of the application deleting. Go to the settings and navigate to the third party installed apps, and make sure yours is removed. A reboot is required (battery pull). On simulator, navigate to the bin/simulator folder in your SDK directory and run the cleanup.bat file to reset the simulator. Then try again. You say that the delete menu doesn't appear, I assume this is on the Third party Installs screen?
A third option is to go into your application descriptor xml file, and check that there is a visible entry point, and that everything is correctly filled in.
Also try doing a refresh and clean build, and checking that all the files are correctly compiling (is there a class file created correctly in your bin folder? And has the distribution folder correctly populated with the cod/jad files for distribution?)
Another option is to re-import the project into your IDE to force the IDE to regenerate some files, and to try loading another project onto the device. If that works an option could be to copy your class files etc over to the new project.
Some of the above are a hassle, but welcome to BlackBerry development!