The second structure will be working behind the scenes and it will contain a small collection of static methods and properties valuable for the default implementation of the protocol’s methods.It’s necessary so the solution we’ll build to be as much flexible as possible, and you’ll understand pretty soon what I mean by that. The first one will be used to specify optionally some settings.It would be a shame though to have a component that fetches, loads and deletes images, but it does not support saving new ones and just for that operation to need a different tool or implementation.Įxcept for the protocol that will be the primary and most important custom type, there will be two additional custom types, two structures: As a bonus point, we’ll add the capability to save a new image locally straight from an app, even though it doesn’t sound like a much related thing to do.
The truth is that we won’t stop there we’ll add more capabilities and we’ll support multiple image fetching, as well as single and batch image deletion. However, what’s the point to get into that trouble if we’re just to create a method that will fetch a single image? Creating a protocol makes it super-easy to integrate image handling capabilities on any custom type simply by adopting it, so in plain words our soon-to-be-implemented solution can be used out of the box everywhere. The main “component” we’re going to implement in this post is a protocol along with a default implementation that will make possible to fetch an image from a remote source, or load it from a local file. So, keep on reading to find out some really interesting stuff. Even if you won’t use what we’ll build here eventually, you might get some ideas to apply in your own solutions.
#Ios swift share image how to#
I’ll show you how to create a handy tool that you’ll be able to use right when it’s needed, and you won’t need to worry anymore about all that I described above. In this tutorial I will present you a simple, yet quite effective recipe that makes fetching remote images and then handling them locally a really straightforward task. The answers though should not be given and implemented when an actual application is being built that kind of issues should be already fixed and be part of the solution, not the problem. Are there any rules about naming or storing details? Are there best and worst practices one should follow? Should images be stored in documents or in caches directory? These and more questions will most probably arise when building an app and it’s about time to deal with remote images. Have you seen this maybe? A perfect chaos and no consistency at all!Īnother troubling point can be the way images are handled locally once they are fetched. It would be really bad to see the app displaying the wrong avatar next to each name, and it would be even worse to have avatar images being replaced by other avatar images when contacts appear and disappear while scrolling. Displaying fetched avatar images to the proper contacts can end up being a hell depending on how image handling has been implemented. Think of the contact list again, which is a list of images with text at its simplest form. When fetching multiple images then it’s really easy to display the wrong image to the wrong place in certain cases.
What makes things complicated is the fact that image fetching is an asynchronous process. Their images must be fetched and handled by the app, and displayed properly when necessary. Or, another example, think of an app that manages the event of a worldwide convention, and among its features is the list of all attendees. When users connect to the app then avatars must be downloaded in order to be used by the app. Those contacts have avatar images residing to a server. For instance, suppose that you’re building the next great messaging application where obviously users have contacts. One of the most common tasks that iOS -and not only- developers are called to perform in their programming endeavours is fetching and managing remote images that should be displayed to an app.
0 kommentar(er)
