Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
Do they use some algorithm such as the ones used in GDIFF program?
Do they ship the intermediate code to the user instead of iOS binary?
Why is it not possible do do a Delta update while updating iOS on Windows?
A delta update is defined as 'an update that only requires the user to download the code that has changed, not the whole program.'
iOS does, in fact, perform delta updates, and contradictory to Ralph's comment, we know exactly how it works.
Applications
For iOS applications, delta updates are used to minimize the download size of new versions, to save internet traffic. Usually, the things that give a program most of its size are the static images and other media. During a simple update such as a bug fix, usually these static images stay the same, and there is no reason to send them over the network again. The only thing that is sent is the actual Mach-O binary containing the code that is buggy, along with whatever files have been changed.
So, delta updates most likely run by checksumming. When you submit an app update, Apple checks the checksum of all files submitted using some algorithm (most likley SHA1 or MD5) to scan for changes. If the executable has changed, but a certain image or other file has not, the image isn't packed with the update, as users have already downloaded it, and don't need to download it again. While this method may not pertain exactly to the definition of a delta update, as it includes executables along with other types of files, it has very similar concepts.
OTA Updates
Apple uses delta updates in over-the-air updates for iOS as well. This is visible on any jailbroken iOS device. Updates are downloaded to /var/MobileSofwareUpdate/softwareupdate.xxxx, where xxxx presumbably is the build/release number. Each software update contains an image of the root filesystem, but not the entire version of iOS is included. Only the files that have changed from the version the user is currently on need to be replaced, and so only those files are included in the update package. The method for finding these changes is likley to be the same as with iOS apps, where checksumming finds changes in the files.
Algorithm
Basically, to answer your question, Apple's algorithm doesn't send the differences between two individual files (similar to what you see in a git commit), but sends the entire updated file. Their 'algorithm' just looks for any change at all between the last version, and doesn't look for the actual change itself. This is proven by the fact that in OTA update packages, the complete files are available, and not just a log of the changes.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
I have an idea for an application where I would like the following to happen:
A group of people / their devices create a sharing session -->
They can set a time frame for this session (could be one hour or one day, but not long term). -->
Once the session is created they will go through their day capturing the data which I want to be shared automatically between all the devices. -->
At the end of the session each device will be able to choose what of the data collected they would like to keep locally on their device despite who may have collected it. -->
Once each of the devices have saved what they would like, the shared storage would be removed.
What I am struggling on is the best technology for sharing the data. I would rather not have notifications each time data is shared.
I have looked at Multipeer Connectivity as a solution, where each bit of data would get sent to each device and stored locally, but the biggest drawback is the inability to maintain a session in the background, which is likely where the application would reside for the majority of the time period.
Any direction or areas to research would be greatly appreciated. Note: at least to start with I would be looking to implement this in IOS
I would imagine a temporary folder on a web server (kinda like shared cloud folders) would be among the better solutions to this.
Doesn't require physical proximity to other participant. Could be in entirely different countries and it wouldn't matter. There's however nothing stopping you from setting such a limitation anyway.
Would be far easier to implement tech-wise. Especially considering cross-platform support.
You espace many logitical problems, such as storage space on individual devies. Like What happens when participant wants to keep some data, but there's not even enough space to even see a preview of what the participant is missing out on.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
After hours of searching, I found like many others that Windows fails to find the driver for my Verizon Ellipsis Tablet. Following the instructions on the support site was no help. Previous forum posts had no solution. My tablet also did not have the drivers on it for ease of install. My solution involves modifying google usb drivers for android to include these devices. I will post the answer as soon as I am allowed to do so.
I am using the Ellipsis Kids but I imagine this will also work for the 7, 8, etc.
Use the official driver if you can find it. Check the support site first.
If you cannot, you may choose to try the following for your own device at your own risk;
Install the google android usb drivers (available through android
sdk manager)
Enable usb debugging on your ellipsis if not done so already; Apps >
Settings > About tablet then tap Build number 7 times
I set usb mode on my device to media via the developer menu (these options vary depending on the device you have)
In device manager find the errored driver device and open its
properties
In the details tab select hardware id's from the drop down and keep
this open
you should see some id values that may very slightly from what i
have below; USB\VID_0408&PID_3883&REV_????&MI_00
USB\VID_0408&PID_3883&MI_00
Now navigate to C:\Program Files
(x86)\Android\android-sdk\extras\google\usb_driver or similar
I suggest you make a duplicate of this folder and work within the
duplicate
Edit android_Winusb.inf with notepad or similar
I added the following lines under [Google.NTamd64] and also under
[Google.NTx86];
;Ellipsis Kids
%SingleAdbInterface% = USB_Install, USB\VID_0408&PID_3883&MI_01
%CompositeAdbInterface% = USB_Install, USB\VID_0408&PID_3883&MI_01
%CompositeAdbInterface% = USB_Install, USB\VID_0408&PID_3883&REV_9999&MI_01
%CompositeAdbInterface% = USB_Install, USB\VID_0408&PID_3883&REV_????&MI_01
You'll note that I made different variations of revision and you
may or may not have to do the same.
You will need to use your own device hardware id's above that you
found earlier (note they can be right click copied)
Save the file
Then navigate to C:\Users\.android and make a
backup of adb_usb.ini
Edit the original adb_usb.ini with notepad or similar
Add the vendor ID 0x408 to the last line in the file
Save the file
Now just go to update the driver through device manager
Point it to the new usb directory you duplicated with the modified
android_Winusb.inf file
Install anyways even though the publisher cannot be verified
Violla I can now download my game to the device
Once actually attempting to send somethign to your device it will
request your approval
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to decompile a iOS 3.1.3 kernel to better understand it, but i'm not sure where to start, But don't be fooled i'm no green horn when it comes to programming.
The kernel is open source so you can view and compile it. iOS 3.1.3 is in the repo but you will also want to look at 3.0.
From Apple:
As the first major computer company to make Open Source development a key part of its ongoing software strategy, Apple remains committed to the Open Source development model. Major components of Mac OS X, including the UNIX core, are made available under Apple’s Open Source license, allowing developers and students to view source code, learn from it and submit suggestions and modifications.
The XNU kernel in its iOS incarnation is not open source, though xnu in its i386/x86_84 (and , for older versions PPC) is.
XNU is built up internally of several layers, with the bottom two - platform expert and ml_* APIs serving as the "glue" to the underlying hardware. This means that without said pieces you could compile the source (with an ARMv7 cross compiler, like the one in the iPhone SDK), but the kernel wouldn't actually boot.
Another difficulty is in the kernel extensions (XNU-speak for "modules"). These are drivers, without which you can't really do much - again, with the kernel not booting since it can't initialize any of its platform dependencies.
Also, contrary to how it may seem, though the iOS and OS X kernels are very similar, there are some subtle differences (which were visible by #ifdef CONFIG_EMBEDDED and #ifdef ARM until after 1699, when Apple realized they were leaking information of use to jailbreakers, and finally used a preprocessor to strip the iOS specific modifications before making it public.
Decompilation is a different matter. It's possible to disassemble and work back, from the kernel image (once decrypted or dumped) through fairly readable assembly (though not to a full source level). IDA and other specialized tools (e.g. jtool) have these capabilities.
There have been at least two projects to get the open source version to compile and boot for ARM. One by Christina Brooks(?) and another by WinOCM. The latter, which has gained notoriety for knowing XNU in its ARM implementation inside out, has eventually been employed by Apple, thereby reducing the chance of any open source implementation ever seeing the light of day.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
The Apple documentation seems to consistently state that the user-generated documents should either all be stored locally or should all be stored on iCloud. Here is one example from this iOS page (the emphasis on All is theirs):
All documents of an application are stored either in the local sandbox or in an iCloud container directory. A user should not be able to select individual documents for storage in iCloud.
I would like to allow users to manage documents individually: perhaps they want one to be local (to save space from their iCloud allowance), another to be on iCloud so they can manipulate it across devices, and another one to be on DropBox so they can copy it out into a friend's account or back it up manually or even edit it externally. The all-or-nothing approach would actually get in the way of flexibility, especially when I come to introduce DropBox sync. In my case, the individual choice also makes for simpler UI.
So the question is: Can I expect trouble at review time if I stick to my plans to allow users to choose their storage preference (local, iCloud and soon DropBox) per individual document? I haven't found specific guidelines for this. Edit: None of the guidelines even mention iCloud.
It's a should, not a must (just as you should support all orientations on the iPad, but I don't think they'll force you to if the UI would need a complete rework). If you have a sufficiently compelling use-case and a non-clunky UI, I suspect they'll let it through, but I haven't tested this.
If it's not in the review guidelines, then I doubt it's ground for rejections apart from any requirement for "usability" — but honestly, given the average quality of UIs out there, I would not be too worried.
(Indeed, a strict interpretation of that guideline is that you're not supposed to use Dropbox/Google Drive/etc/roll-your-own-cloud-storage, but that's almost certainly not the intent unless they're inviting antitrust lawsuits.)
I did a lot of testing for an app with iCloud. I started with the supposition that it would be transparent to the user whether everything was in iCloud or not, otherwise why would Apple suggest this approach?
Unfortunately, they did not test this fully before rolling it out. I had many problems in iCloud and UIDocument with iOS 4 then 5 (many radar entries of bizarre crashes). In fact, I probably spent half my development time working on this one issue rather than making the app better.
Anyway, the bottom line was that my app was MUCH slower when accessing docs running only on the cloud. Apple does try to cache docs in the Mobile Documents directories. There is minimal info on how to determine status of the caching and therefore try to work around unavailable docs or slowness. The UI ended up extremely jerky in the UITableViews or outright crashed in system libraries.
So, bottom line is my app stores everything locally. If a user makes a change, the app copies it up to iCloud itself and runs background processes to monitor the status of the doc getting up to the cloud. It also manually transfers files changed by another device on iCloud to keep everything in synch, again in background processes.
I've had no complaints at all from Apple reviewers. If I did, I would point them to the many radar entries.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
The guidelines for iOS and the Mac App Store state that demo versions of apps are not allowed.
As far as I can tell, a lite version is (most of the time) just a demo with an IAP for the full version (so as to retain progress)
A "demo" app is traditionally a fully functional app that only runs for a limited time or doesn't let you save anything, or is crippled in some way to make it useless beyond being a demo.
A "lite" app is fully functional in its own right. If a user never upgrades to the full version, the lite app must still do something useful, even if it is fairly limited. One critical thing Apple will look at is no part of the UI must be disabled in a lite app. If a bit of functionality doesn't work in the lite version, then it must not be part of the UI at all.
In a lite app you may have a button or other UI element that lets the user upgrade. If the user reaches some limit imposed by the lite version, you may inform the user that they can upgrade if they wish. But never prompt the user out of the blue to upgrade.
A lite app does not require IAP. You can create a pair of apps (lite/paid) instead if you wish.
If you decide to use a single app with IAP to upgrade, don't call the app "Lite". Don't put "lite" in the icon. Because if you do, your customers will hate you once they upgrade the app and it still says "lite" anywhere.
Provided you're not putting any sort of time limit on your application, or removing functionality from the game - it'll pass as a lite version.
The "removing functionality" limitation is one of those ambiguous statements. You wouldn't get away with removing the "Save" function from a text editor, though you would get away with not having a different model of car in a racing game, or by having it as an IAP.
It's all rather subjective