This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Using libFirstConfig.a in iOS app



I am writing an iOS app that uses the libFirstConfig.a library for Smart Config provisioning. I have two questions:

  1. Would it be possible to get a version of the library that will allow my app to run in the iOS simulator. I need it to have x86_64 and i386 support, which it currently does not. It just has universal binary support for iOS devices, which is good, but I need to be able to test my app on the simulators too.
  2. What is the minimum set of files I need to run Smart Config. The Wifi Starter app source code includes the following files. Do I need them all? I've done some search analysis of the TI app source code, and I could experiment and try removing one at a time, but I'd like a more definitive answer of whether I need to include them all in my app for Smart Config to work properly.
    1. FirstTimeConfig.h - I know I need this
    2. FTC-prefix.pch
    3. FTC.plist
    4. Ftc20.h
    5. FtcEncode.h
    6. NetworkHelper.h
    7. NSData+AESCrypt.h - I assume I need these next two files if I need AES encryption during Smart Config?
    8. NSString+AESCript.h

Thanks.

-Mark

  • I see this thread is making it's way down into the depths of the forum, where threads go to die.

    Would appreciate some response from a TI engineer on this.

    Thanks.

    -Mark

  • Hi Mark,

    We'll get back to you on this one.
  • Hi Mark,

    We don't have the library in x86 format so you'll need to have an iOS device to work with for development.
    All header files are required are they are part of the app.
  • Hi Victor,

    Well, that's not the answer I wanted to hear, but I do appreciate you getting back to me.

    Thanks,
    -Mark
  • I am with Mark, this has been quite an annoying aspect of working with SmartConfig from within an iOS app.

    The biggest issue is that the emulators allow you to test for the multiple screen sizes and iOS versions that iPhones and iPads now come in. To restrict the user to having to use devices means many combinations of devices are unable to be tested, as even the largest mobile development teams are unlikely to have all the combinations in hardware.

    Please reconsider this situation if it is at all possible.

    Glenn.
  • Hi Mark, Glenn,


    We'll take it into consideration.

    One suggestion: the App GUI development can still run on the emulator without the Smart Config library. Instead of loading the library, you can use some dummy code to be the place holder. Once the library needs to be linked to perform actual testing on the functionality on a device, you can simply replace those sections.

  • Victor,

    This misses the point. You provide a library that your customers need to use in order to implement Smart Config in their iOS applications for the product they are building. I'm sure you would like as many customers as possible using your Smart Config products. Potential customers of your products use a lot of different criteria in evaluating whether they are going to use TI or use another vendor. Forcing your customers to jump through hoops and deviate from their normal development workflow is a big checkmark on the negative side of that evaluation. I see Glenn brought this up a couple of years ago, and he makes the same arguments:

    e2e.ti.com/.../298073

    The fix for this is so simple. It's a matter of building a couple more static libraries (for x86_64 and x386) and bundling them together into a fat static library. As Glenn stated in the thread above, a simple google will give you the information you need to do it: "how to create iOS universal static library". If we can be of assistance, I know I would give my time freely to help you get this done. It really should not take more than 10 minutes. If the answer to why you can't just get this done for us is that you don't want to support Smart Config issues that might arise when running on the simulators, then just make that statement in your documentation, but at least give us the ability to run our apps in the simulator by providing a universal library that has support for the the required architectures.

    -Mark
  • Hi Mark,

    I apologize for the inconvenience and I completely agree with you.
    I've already raised this issue to the higher management level. Thank you for the suggestion.
  • Hi Victor,

    Can I get an update on this? I'm wondering if we can expect to have a universal binary that lets us run on the simulators anytime soon?

    Thanks.
    -Mark
  • Hi Mark,

    Unfortunately, we won't be releasing this binary in x86 format any time soon.

    We stated in the Provisioning Wiki page that Smart Config is not the recommended provisioning method from TI and developers should always have a backup solution like WPS or AP mode.

  • Victor,

    Maybe you can pass this on up the line too. When you tell your customers that you can't support them with a reasonable request that would help them use your products, especially when the solution would, seemingly, be trivial, it would be good to provide an explanation of the decision to not support your customers, other than "We won't be doing this anytime soon." Seriously, you might as well just say, "sorry, this is never going to happen". At least there would be no ambiguity. It's clear this is never going to happen, because it has been requested for at least 2 years by other customers, and you are saying the same thing today as you did back then. Yet, never an explanation.

    I'm sorry, I understand this is probably not your decision personally. The lack of support on this, as well as other issues, is just very frustrating.

    -Mark