Since iOS 10, when Apple made a major revision to widgets, many people have developed their own widgets. There are also many tutorials online that tell you how to quickly develop a widget. This article will not repeat those simple things like creating extensions and adding certificates. We need to take a deeper look at what a widget should look like. Do you really understand the size of the widget? First, the widget has two states
Most online tutorials will tell you that if you want to change the height of a widget, you should do this in the following method:
This means that even if the folded state is 110, the expanded state is 300. Because if you write 120 in the folded state, the height is still 110, and this height will not change. In the expanded state, of course, a value smaller than maxSize.height must be taken. So what is the value of maxSize? However, I want to tell you that the height is not a fixed value at all! And it can be considered irregular!!! Because the ultimate rule of the maxSize limit of the entire widget is to change according to the system font size. Whether in the folded state or the expanded state. In other words, it is wrong to directly write 110. Because under the default system font, the folded height is indeed 110. But once the system font is changed to the smallest, the height of the widget in the folded state is only 95, and when the system font is the largest, the height of the widget in the folded state is 140. The system font size has 7 levels. In other words, the folded height is related to the font size, but not linearly. It can be verified that the folding height is 95-100-105-110-120-135-140, and it cannot be modified. The folded height is fine. The unfolded height is also a non-linearly related height (and this is when the folded height is uniform). The following discussion on expansion heights fixes the system font size as the default size and controls the variables (the final size result, in theory, multiplied by 7 is the total possible height). First of all, there are differences in the models. Of course, the smaller the phone screen, the smaller the expanded height will be. This is actually acceptable. At worst, we can develop according to the smallest screen. However, I want to tell you that the widget's maximum height will still change! This is our most common widget entry, which is the Today page when you swipe left on the screen. However, there is actually another entrance, which is to swipe left on the pull-down notification page. When these two entrances come in, the maximum height of the widget in the expanded state will be much smaller than the former! It is easy to verify by looking at the maxSize breakpoint. In the default font size of iPhone7, the maxSize.height of the first entry is 616, while in the other case, this value becomes 528. At this point, I really want to ask Apple, what on earth is this trying to do? There is actually a third entry point, which is the 3D touch app icon, which also has a widget, but that one is only in the folded state. That is to say, at present, there are 7 sizes in the folded state, and each screen size has 7*2 sizes in the unfolded state. That is to say, if the three mainstream screen sizes of 4 inches, 4.7 inches, and 5.5 inches are to be adapted, the unfolded state will have 7*2*3=42 sizes. Seeing this, you can say, it doesn't matter, I'll just take the minimum height of 4-inch devices. This depends on whether your designer can agree. Do you think it’s over? Let alone the iPad, let’s not consider that. If it can hold an iPhone, it can certainly hold an iPad as well. But you really can't imagine that the 5.5-inch Plus model in landscape mode is also different sizes. In the Plus horizontal mode, the maximum height of the first entrance is only 352, and the maximum height of the second entrance is only 264... What does this mean? In the *** font case, the folded state has a height of 140, and the unfolded state is less than twice the folded height. If you are interested in widget size adaptation and have a solution, please contact me and I will reward you handsomely. Do you feel blinded? If you add a lot of widgets, you will find that just swiping up and down in the list can be blinding. The update mechanism of the widget itself is to execute the viewDidLoad method first and then the viewWillAppear method after entering the widget. However, after testing, every time a widget slides up or down and slides out of the screen, and then swipes the widget back, the above refresh mechanism will be used. Due to the above characteristics, the update code should be written in the viewWillAppear method. For apps with particularly strong timeliness, such as weather apps, the best way is to add an NSTimer to the method for scheduled refresh, and cancel the NSTimer invalidate scheduled update in the viewWillDisAppear method. Alternatively, you can implement caching yourself, which can also be optimized. If the requested data is consistent with the current data content, then do not refresh the list. The widgets of many apps such as Zhihu and Get will flash as long as they use the viewDidLoad method, because each time the widget loads the requested data, it will be replaced. As for why it refreshes as soon as you are out of sight and come back, I guess it is because of memory problems. The memory requirements of widgets are outrageous. Once there is a gif in your widget, it basically cannot be displayed at all, and it will show that it cannot be loaded after a while. Not only that, repeatedly scrolling the widget page back and forth to refresh it will also cause the memory usage to increase. I am not sure if this is an Apple bug, but in my own tests, I try to make the memory usage of a single widget less than 15M, so the chance of being killed is very small. Therefore, when I was developing, I only took the last frame of the gif image, and tried not to actively refresh the UI to keep the widget memory at a low level. And because the extension cannot actually directly use the frameworks in the main target, I also wrote some basic functional components. The first is of course the cache system, and image cache is particularly critical, because the characteristics of widgets will be refreshed repeatedly, and if there is no cache system, it will be a huge waste. The first is image cache:
A very basic image cache, which works with the file management class to manage the response returned by the interface: The controller sends a request and caches and compares the response data when it receives it.
File management class is used to store
***This is the file structure of one of my widgets. Although the widget is small, I still tried to make it as complex as possible when I was developing it. After all, this kind of thing, once developed, will almost never be touched again. After all... dancing on the tip of a needle with shackles is too tiring 😂. |
<<: Custom View-Imitate the reward button of the Hupu live broadcast game interface
>>: Miscellaneous: MVC/MVP/MVVM (Part 2)
After more than two years of planning, Didi final...
After using our eyes for a long time, our eyes wi...
My classmate's aunt is 52 years old, looks ve...
Produced by: Science Popularization China Author:...
On September 1, the world's leading academic ...
On March 2, Jilin City discovered infected people ...
Google announced that it is closing the door to t...
Recently, the Beijing Municipal Administration fo...
Since Bungie was acquired by Microsoft in 2000, &...
According to the latest report from SellCell (Int...
2017 is still a period of rapid development for i...
The full launch of Intel's 100 series motherb...
Most employers have a misunderstanding about new ...
Last month, the 2025 Deep Blue SL03 was officiall...
[[136824]] How did Jobs develop his pursuit of su...