Have you ever encountered a bug that you weren’t able to reproduce in the iOS Simulator but only later discovered that it is only reproducible on the actual device?įor me, that situation occurs more often than I’d like but it’s not all that surprising because as good as the Simulator is, at the end of the day, it is meant to simulate a real device. Click “Request” or “Response” to view the actual data of the network request or response.īy inspecting the requests that your app is making and the data that is coming back, you’ll be able to identify issues that may end up causing you hours of headaches down the road. You’ll notice tabs near the top of the right hand side. On the right hand side, you can see an overview of that specific network call such as latency, time elapsed etc. Select a request to see the detail on the pane on the right hand side. You can expand the tree nodes to see the actual requests. On the left hand side, you can see the top level domains that your app is making requests to. The proxy is monitoring all the network traffic from any app that you’re running.īelow is a screenshot of what Charles Proxy looks like. ![]() When you open Charles Proxy, don’t be alarmed if it starts logging things that your app isn’t connecting to. Monitoring that network traffic coming in and out of your app is as simple as having Charles Proxy open while you’re testing your application in the iOS Simulator. And anything else that relates to your app making/receiving network calls/responses!įor any of the scenarios above and more, the first thing I would do is double-check that my app is sending the request and parameters that I’m expecting it to, and secondly, that my app is receiving the responses that it is expecting. Your app is making a call to some API and you’re not receiving the expected results.Ĥ. If you app is sending some data to a server to be saved or processed and you’re not getting the expected result.ģ. If you see an empty screen in your app when it’s supposed to fetch some data and display it, then the first thing I would check is if the data is actually being returned from the network request.Ģ. Here are some scenarios where using Charles can be handy:ġ. In this way, you can actually capture the network calls that your app is making and what responses it is getting back. Your most basic use of Charles will be just having it running in the background while you test your application in the iOS simulator in Xcode. Testing Your App In Various Network Conditions ![]() The sole purpose of writing this article is to show you guys how I use the tool to ease my iOS development and hope that it can help someone else as well.Īlright, let’s start with some scenarios you might encounter:ĭebugging Network Issues That Only Occur On Devices I’m sure there are other types of tools out there that allow you to do the same thing but I really enjoy how easy Charles is to use.ĭisclaimer: I’m in no way related or affiliated with the developer, Karl von Randow, nor am I getting paid or compensated to write this article. With Charles, you’re able to peek into the network requests and responses that your app is making/receiving. In times like those, being able to see what is being sent and received across the wire is invaluable and time-saving. If you’ve had to build any sort of connected iOS app, I am pretty sure you’ve cursed at the iOS gods at one point or another when debugging some intermittent, hard-to-reproduce network bug. I also do a lot of work daily involving video streaming to iOS devices. ![]() Every day, I’m building and working with applications that connect to remote data sources whether they’re files, feeds, databases, etc.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |