In the previous post, we talked about a browser plugin or a provider specific dedicated app for trying out REST APIs. However, they are either browser tied or API service provider tied. In
this post we talk about the system requirements for a Fiddler mobile app. We specifically target the IOS SDK as an example.
When I develop the application for a Fiddler UI on iPhone, the following are the requirements from IOS SDK:
1) single user for single device - This means that only the current user has the ability to capture traffic. The features are tied to the device and not the user. There is no login for the
application. Moreover, the application is a different instance on each device for the same user
2) ability to change proxy - This means that the application works with only the proxy for the local device. Ability to change proxy for the duration of the application is critical to the traffic capture. By replacing the proxy with our own, we will be able to listen in on the traffic.
3) The notifications corresponding to switching in and out of applications by the user, so we can resume where we left off or operate in the background.
4) The ability to persist captures to disk so we can load them again. In the case of mobile device, we may not want to let the user save and reload captures since such action can take a lot of space. However, the ability to save captures for the current session internally is important.
5) The ability to persist cookies for the user so that his or her settings may be remembered.
6) The ability to cleanup persisted files and settings so that the application can start as if from a clean state. This also means install and uninstall should work correctly.
this post we talk about the system requirements for a Fiddler mobile app. We specifically target the IOS SDK as an example.
When I develop the application for a Fiddler UI on iPhone, the following are the requirements from IOS SDK:
1) single user for single device - This means that only the current user has the ability to capture traffic. The features are tied to the device and not the user. There is no login for the
application. Moreover, the application is a different instance on each device for the same user
2) ability to change proxy - This means that the application works with only the proxy for the local device. Ability to change proxy for the duration of the application is critical to the traffic capture. By replacing the proxy with our own, we will be able to listen in on the traffic.
3) The notifications corresponding to switching in and out of applications by the user, so we can resume where we left off or operate in the background.
4) The ability to persist captures to disk so we can load them again. In the case of mobile device, we may not want to let the user save and reload captures since such action can take a lot of space. However, the ability to save captures for the current session internally is important.
5) The ability to persist cookies for the user so that his or her settings may be remembered.
6) The ability to cleanup persisted files and settings so that the application can start as if from a clean state. This also means install and uninstall should work correctly.
No comments:
Post a Comment