7 ms·

Thanks for taking a look at our SDK. We actually put in all the comments on the interface file to clear up confusion people had when using the API.

by sskates 13y ago

seivan 13y ago
Yeah I figure, but notice how Apple keep their documentation outside of their interface file. Try that. It makes it easier to learn.
seivan 13y ago
You probably want to do three things 1) Extract all network layer into its own stuff. We built an SDK recently, and I decided to make three layers out of it. SDK -> OAuth2 -> Networking 2) Separate that 1000 lines of code into several classes (check #1) 3) Update your device naming https://github.com/seivan/mixpanel-iphone/blob/feature/proper_naming/Mixpanel/MPDeviceNamer.m https://github.com/seivan/mixpanel-iphone/blob/feature/prope... You guys will run into a case where your users will pollute their tracking with unknown model names because your SDK was outdated on the naming. Even if they do update the SDK, the users will have ton of data with the old naming. I'd probably store the device naming map on the server side in case of new devices without having to update the SDK. Also, write tests, add a sample app, add your cocoapod spec file to your repo as well - etc.
- sskates 13y ago
  Thanks for the suggestions! We're on cocoapods, have tests, and a sample app locally but haven't pushed all that to Github to keep things simple for everyone looking at the source. Model name tracking is an issue- we've fixed it in our backend so we can remap unknown names to display the correct thing on our website interface. We just haven't yanked the code from the SDK. Agree on rearchitecting it with separation of concerns. We have to be very careful with any changes we push. The code's already running successfully on 10MM phones without any issues and we have to make sure not to introduce any new ones- so that process takes a while. Thanks again!
  - je42 13y ago
    If you have a complete suite of unit tests, integration tests and system tests, you should not have fear on refactoring your code. Question: do you store events that could be not send in a persistent store to retry at a later stage ?
    - sskates 13y ago
      It's true that tests are very helpful for this. However there are a lot of bugs in the wild that are difficult to reproduce, especially ones that will only crop up under rare conditions of state. It's as Linus said- "There really are only two acceptable models of development: think and analyze or years and years of testing on thousands of machines". Years and years of testing on thousands of machines happens to be the best predictor of code that runs correctly.
  - je42 13y ago
    [Amplitude generateRandomId]; --> is that persistent per device ?
    - sskates 13y ago
      It's persistent across app opens, not across installs though. We were using AdvertiserID for tracking but Apple started clamping down on that so we've switched over to to vendor ID, which they explicitly recommend for things like this.
  - je42 13y ago
    Ok, and next question: logRevenue why only accept dollar ? This puts the burden of estimating dollar revenue received from different currencies on your customer. ( which is a common case for global mobile apps... )
    - sskates 13y ago
      It's not a dollar amount, but any NSNumber value. We'll provide support for localization down the line.

Thanks for taking a look at our SDK. We actually put in all the comments on the interface file to clear up confusion people had when using the API.

by sskates 13y ago

Thanks for taking a look at our SDK. We actually put in all the comments on the interface file to clear up confusion people had when using the API.

seivan 13y ago

Yeah I figure, but notice how Apple keep their documentation outside of their interface file. Try that. It makes it easier to learn.

seivan 13y ago

You probably want to do three things 1) Extract all network layer into its own stuff. We built an SDK recently, and I decided to make three layers out of it. SDK -> OAuth2 -> Networking 2) Separate that 1000 lines of code into several classes (check #1) 3) Update your device naming https://github.com/seivan/mixpanel-iphone/blob/feature/proper_naming/Mixpanel/MPDeviceNamer.m https://github.com/seivan/mixpanel-iphone/blob/feature/prope... You guys will run into a case where your users will pollute their tracking with unknown model names because your SDK was outdated on the naming. Even if they do update the SDK, the users will have ton of data with the old naming. I'd probably store the device naming map on the server side in case of new devices without having to update the SDK. Also, write tests, add a sample app, add your cocoapod spec file to your repo as well - etc.

sskates 13y ago
Thanks for the suggestions! We're on cocoapods, have tests, and a sample app locally but haven't pushed all that to Github to keep things simple for everyone looking at the source. Model name tracking is an issue- we've fixed it in our backend so we can remap unknown names to display the correct thing on our website interface. We just haven't yanked the code from the SDK. Agree on rearchitecting it with separation of concerns. We have to be very careful with any changes we push. The code's already running successfully on 10MM phones without any issues and we have to make sure not to introduce any new ones- so that process takes a while. Thanks again!
- je42 13y ago
  If you have a complete suite of unit tests, integration tests and system tests, you should not have fear on refactoring your code. Question: do you store events that could be not send in a persistent store to retry at a later stage ?
  - sskates 13y ago
    It's true that tests are very helpful for this. However there are a lot of bugs in the wild that are difficult to reproduce, especially ones that will only crop up under rare conditions of state. It's as Linus said- "There really are only two acceptable models of development: think and analyze or years and years of testing on thousands of machines". Years and years of testing on thousands of machines happens to be the best predictor of code that runs correctly.
- je42 13y ago
  [Amplitude generateRandomId]; --> is that persistent per device ?
  - sskates 13y ago
    It's persistent across app opens, not across installs though. We were using AdvertiserID for tracking but Apple started clamping down on that so we've switched over to to vendor ID, which they explicitly recommend for things like this.
- je42 13y ago
  Ok, and next question: logRevenue why only accept dollar ? This puts the burden of estimating dollar revenue received from different currencies on your customer. ( which is a common case for global mobile apps... )
  - sskates 13y ago
    It's not a dollar amount, but any NSNumber value. We'll provide support for localization down the line.