[Rejected] SDL 0047 - Manual layout for SDLLockScreenViewController about sdl_evolution HOT 4 CLOSED

@joeljfischer in reference to the conversation we were having before this was pulled into review, I believe we found a solution that should prevent the need to manually copy assets over to each individual implementation. Below I am posting an update sdlBundle function that has solved the problem in our SDL test applications.

+ (nullable NSBundle *)sdlBundle {
    NSBundle *sdlBundle = nil;
    
    NSBundle *localSdlBundle = [NSBundle bundleForClass:[SDLManager class]];
    
    NSURL *sdlBundleURL = [localSdlBundle URLForResource:@"SmartDeviceLink" withExtension:@"bundle"];
    sdlBundle = [NSBundle bundleWithURL:sdlBundleURL];
    
    if (sdlBundle == nil) {
        @throw [NSException exceptionWithName:NSInternalInconsistencyException reason:@"SDL WARNING: The 'SmartDeviceLink.bundle' resources bundle was not found. If you are using cocoapods, try dragging the bundle from the SmartDeviceLink-iOS pod 'products' directory into your resources build phase. If this does not work, please go to the SDL slack at slack.smartdevicelink.com and explain your issue. You may disable the lockscreen in configuration to prevent this failure, for now." userInfo:nil];
    }

    return sdlBundle;
}

I would also like to offer an alternative opinion on some of the other benefits listed in this proposal:

Creating assets in this way should also slightly improve the size of data we require developers to import in order to use the library. They are also more flexible, as these assets can change color and more easily scale than PNG assets.

A lot of these benefits can be achieved by using pdf/vector assets instead of PNG assets. This should enable all of the easy scaling and custom color benefits that a code solution would create, while allowing designers to cut assets without the need of Paintcode. I do not believe the data size should be a major issue since the app store now supports resource slicing, which can reduce the download size of an application substantially automatically.

Laying out the lock screen via code has advantages as well. We have seen warnings due to backward compatibility with storyboards, by using raw code to lay out the screen, we would avoid this. Developers unfamiliar with storyboards would be able to more easily understand and modify how it is laid out as well.

Storyboards can certainly be warning-heavy, but it shouldn't cause any compilation/performance issues. Outdated storyboards can generally be upgraded automatically via xcode. I have found that most iOS developers/designers are more familiar with the interface builder than manually instantiating view objects and laying out constraints via code. I have concerns that switching to a code/manual layout solution could potentially alienate people on the implementation side, as well as new contributors to the project.

This seems to be a subject of great debate even within the iOS development community, but we felt that these concerns should be raised. Since the assets/storyboard issue seems fixable pulling in the above solution we are not sure we see the benefit to converting everything over to a code-only solution.

from sdl_evolution.

Since this proposal was submitted, we have fixed one of the major issues this proposal sought to solve: smartdevicelink/sdl_ios#602

There are still benefits to this proposal, to respond to @Toyota-BSalahat

A lot of these benefits can be achieved by using pdf/vector assets instead of PNG assets. This should enable all of the easy scaling and custom color benefits that a code solution would create, while allowing designers to cut assets without the need of Paintcode.

Unfortunately, pdf / vector assets are still very poorly supported by Xcode. To use vector, we would need to use a 3rd party library. We could use pdf, but they're certainly 2nd class citizens in Xcode and don't have the coloring benefits they should, as far as I know.

I do not believe the data size should be a major issue since the app store now supports resource slicing, which can reduce the download size of an application substantially automatically.

This is true, but code assets would still be substantially smaller.

Storyboards can certainly be warning-heavy, but it shouldn't cause any compilation/performance issues. Outdated storyboards can generally be upgraded automatically via xcode. I have found that most iOS developers/designers are more familiar with the interface builder than manually instantiating view objects and laying out constraints via code. I have concerns that switching to a code/manual layout solution could potentially alienate people on the implementation side, as well as new contributors to the project.

I actually disagree with this point. They do take substantially longer to compile than code, though that isn't a huge issue for us because we have so few (namely, one). Outdated storyboards can be upgraded by Xcode, but that also means that people using newer / older Xcode versions can be left out or upgrade storyboards when we don't want them to. We've run into this problem before. There's also the "touching" storyboard issue where simply opening it can change it, making pull request reviews more difficult. As far as a manual layout alienating people on the implementation side, I have generally found that 1/2 or more iOS devs do layout in code anyway, and certainly most at larger corporations, either due to trying to avoid merge issues, or comfort, or whatever. I don't think this will be a large barrier. We're still using autolayout here, it will not be too complicated.

from sdl_evolution.

@joeljfischer

Unfortunately, pdf / vector assets are still very poorly supported by Xcode. To use vector, we would need to use a 3rd party library. We could use pdf, but they're certainly 2nd class citizens in Xcode and don't have the coloring benefits they should, as far as I know.

Maybe we should discuss offline, but I would be interested to hear more about this. My previous role was at an app consultancy and pdf assets seemed to be pretty standard with all of our clients. They handle per device scaling at compile time, and have always allowed color shading via the "tint" property. It also allows you to maintain a single asset, instead of having to handle 1x, 2x, 3x, etc individually.

This is true, but code assets would still be substantially smaller.

While true, it seems the combined image asset directory in iOS proxy for assets across all devices is around 131KBs. With app slicing about 1/3rd of that content (each device only needs 1 out of the 3 image resolutins) would be downloaded to a device from the app store, which would be around 44KBs. Either of those numbers is a fairly negligible amount in the context of an iOS/Android app. I am not sure this should be a consideration in this case.

actually disagree with this point. They do take substantially longer to compile than code, though that isn't a huge issue for us because we have so few (namely, one). Outdated storyboards can be upgraded by Xcode, but that also means that people using newer / older Xcode versions can be left out or upgrade storyboards when we don't want them to. We've run into this problem before. There's also the "touching" storyboard issue where simply opening it can change it, making pull request reviews more difficult. As far as a manual layout alienating people on the implementation side, I have generally found that 1/2 or more iOS devs do layout in code anyway, and certainly most at larger corporations, either due to trying to avoid merge issues, or comfort, or whatever. I don't think this will be a large barrier. We're still using autolayout here, it will not be too complicated.

There are a few good points in here. I have seen some compile time slow-down from singular, bloated storyboards, but generally not from smaller ones, or even clusters of smaller ones. As you mentioned, this probably will never be a factor in SDL.

I believe your points about upgrading/non changes from opening the file are valid, but I also think they are easily caught in review of a pull request, and are easy to revert using git. In my career, I have found that around 3/10 developers are comfortable with code-only interfaces, and a smaller subset of those that are comfortable reading/maintaining autolayout without being able to visualize it in a storyboard. Playgrounds, IBDesignables, and stack views help with this, but the comfort level I have seen has favored xibs/storyboards.

I do think Apple is nudging towards storyboards (WatchOS only supports storyboards), but it has always been a controversy with iOS. I don't think there is a right or wrong answer, but I do think storyboards have a lower barrier to entry and that can be a pro when it comes to long term maintenance.

from sdl_evolution.

This proposal has been rejected by the Steering Committee. The biggest reason for this proposal is no longer an issue, as it was fixed with smartdevicelink/sdl_ios#602. As such, the actual benefits of this proposal are now outweighed by the work and changes this proposal would require.

from sdl_evolution.