If you have the .IQ file, you can find the debug.xml in there. You'd need to unzip that file and then locate the folder for the correct device based on the device part number (you can see which part numbers map to which device in ${SDK_ROOT}/bin/devices.xml.
If you have your source code in revision control (you are using revision control, right?)
If you have a tagged revision that you could sync back to and rebuild the debug.xml as it was.
If you know the date/time you built the released version, you could sync back to that date and rebuild the debug.xml.
Someone with access to the app store backend could probably download the .IQ file for you. Unfortunately, I don't have the access needed.
I don't believe it was intended to be intuitive. Users shouldn't need to crack them open, so it wasn't a concern.
The IQ file needed to be a container to hold a collection of other files. By using .zip under the covers, we get a free container format and we get portable compression without any additional work on our part. The decision to use a unique file extension for a zip file used in this way is not uncommon. Java's .jar files and Microsoft's .docx, .xlsx and .pptx files have done this for years. By using a unique file extension, we avoid users trying to upload the wrong files from their desktop.
Yep it’s very common, and with those other examples (and others not mentioned, such as certain types of shared files), having a unique extension means the appropriate app can open the file and interpret the contents as necessary, while still using a ZIP container with all the benefits of that (like a common standard, compression, multiple files in one container and checksums to ensure integrity)
Travis.ConnectIQ Maybe a compromise could be that the CIQ plugin could try to register IQ files with the OS’s default archive handler? Or provide its own wrapper? Or maybe just some text on the Export Wizard dialog explaining what an IQ file is?
I can see how noobs would have trouble with this.
However, on Windows at least, apps like 7-zip are able to detect that an IQ file is a zip and give you the option to open as an archive, although you have to proactively right-click on the file and look for the appropriate option in the context menu.
On linux and Mac OS, running the file command against an IQ file should inform you that it’s a zip, although that’s not exactly intuitive.
Maybe a compromise could be that the CIQ plugin could try to register IQ files with the OS’s default archive handler? Or provide its own wrapper? Or maybe just some text on the Export Wizard dialog explaining what an IQ file is?
If someone really wants to add add an association for .iq files, they can do that. There are already several ways you can get at the guts of the file (unzip myapp.iq -d ., python -m zipfile -e myapp.iq ., ...), but the fact remains... we don't want anyone to have to open the .iq file in the first place.
We already have a plan in place for how to address this. It does not involve making it easier for users to do something we don't want them to do. Just BE PATIENT.
If you have a tagged revision that you could sync back to and rebuild the debug.xml as it was.
If you know the date/time you built the released version, you could sync back to that date and rebuild the debug.xml.
. [/LIST]
I can retrieve and rebuild the revision, but where can I find the debug.xml from my rebuild using the sim (Eclipse/ MacOS)? (I don't have the crashing user's device.)
If you have the source you can build everything you need. Just click Connect IQ > Build for Device Wizard..., then make sure to select the correct device, check the Build release version of project option, and check the Include debug XML alongside the executable, then click Finish.
