Responsibility - TableViews and Leadership

It's been a very long time since the last post, lost of reasons, moving cities, roles, etc. As a Technology/IT leader with the organisation, it was expected to not talk about the technology due to their state of being in the life cycle of the organisation. In addition there were more things that were non technology related that were enablers and also show stoppers. It's been a real interesting ride over the last 2 years to see how things have evolved and still remained the same.

First the Gripes/Whinge

Just as the Genie says when he came out of Aladdin's lamp, "10,000 years will give you a such a crink in the neck". Working through a fluid technology industry can do something similar, so a whine on and off is good.

It seems like yesterday when Chris Lattner introduced Swift, I wrote my book/s and met Chris, who was staying at the same hotel as me during WWDC'16. However when he left Apple for Tesla, it was quite a spectacular moment when everyone thought they would now program a Tesla with swift. However just 6 months later when he publicly announced that he is leaving Tesla, it was disappointing to see how the internet was making fun of if they had jobs for him. Things change, though he is still on the Swift Open Source Team, it is not surprising that he had to tell some of the maintainers on how to behave and demonstrate leadership and set the tone because others will follow their lead.

In a scaled down version from that segue, is the number of people that I have met during this last year that are calling the shots (in IT Leadership roles) for organisations that affect or potentially affect the lives of many. While there are a few that are amazing people, there are the majority that are in the role because the person in the role moved out and they filled into the position. The real danger here is the lack of leadership or ability to fulfill that role.

The other thing is the language, It is almost like "The Revenge of the Web Developers - Part II". While majority of the organisations are looking for a quick win, they are considering options like React (and it's variants). Look around everywhere, it is Java or JavaScript, there was also an article on medium, if I recollect it right, it's title was "I have seen heaven and it is written in JavaScript" or something to that effect. I have nothing against Javascript, it was in fact on the languages that I started tinkering with around 1996-97. However, it never offered anything more than scripting in the browser and since IE was the dominant browser, VBScript was a better candidate as it also ran scriptlets on the desktop with something called the HTMLApplication (.hta).

Then Came PhoneGap, that allowed Web Developers to quickly wrap their web projects into an App and publish on the App Store. This kind of peaked and soon died down. Alternatively there were a lot of frameworks that used OpenGL as the basis to provide a cross-platform single-source application. These also peaked and well, kind of disappeared, while a couple remain but the focus once again shifted to Native Application. Then came Swift, everyone was excited and it was a relief to not use Objective-C anymore, which in hindsight might not have been such a bad thing had the advancements made now be introduced earlier. The entire issue is that while Swift is a fully featured language, to use it for anything it relies on the host architecture which is basically the Objective-C Runtime that stemmed from the NextStep Objects (NSObjects). This is exactly the issue that Google would face if they try to open the system for use with Swift. This is where JetBrains saw an opportunity and introduced their offering in the form of Kotlin, which is not integrated into Android Studio as the alternative language, just like Objective-C and Swift for Apple, it is now Java and Kotlin for Android.

Back to the Single-source, the cross-platform, silver bullet that everyone seems to try to find. React Native sits in that exact same space at this point in time. It is the quick win for startups to reach out to their potential customers with all possible platforms. What is the longevity of this, it is still unknown, but from a lot of developers that are working with Native Swift or Objective-C, they are contemplating moving to React or face being phased out by the full stack that insist on React as it fits right with their Angular and Node stacks, notice the subtle JavaScript proliferation...

On the other hand there are the purists and academics that are on about functional programming and thereby pushing interest back to languages like Haskel and providing alternatives like Scala, Rust, Elm, etc Some of which are not usable in production code.

Part II - The more it changes the more it remains the same

A little more near home, iOS development. It is surprising that it is nearly 2018 and we are still struggling and debating about writing code in an ever new paradigm, starting from MVC, MVVC, MVVM, MVVMC, VIPER, RIB, etc. This all started with the two layers Client and Server, where the code ran on either end, either the client or the server. The code was moved to either to take advantage of the processing and reduce the data that flows through the connection as Data used to be a scarce resource, both the network and disk space. From those 2 letter we moved to 3 with GUI, using a MVC. Just like the multiple javascript variants, we have a new paradigm being made up every other week. Now we have co-ordinators, controllers, routers, Interactors, presenters, and what not. Look at the parallel, from the developer that did everything from the 60's - 90's, we started to thin that responsibility by splitting it over to other roles. After a few iterations, we have a role for each aspect of development BUT we are back to asking for a full stack developer that can do end-to-end. There is a parallel to the way we keep going. The most interesting part that no one would admit to is that presenter of the idea might have presented it while toying with something and upon validating would never want to use that again, however some zealots would have taken it to the max and pushed it as the new de-facto standard. It is logical, make something new that only you understand and no one else, you will have a more stable position than others as they catch up to it and adopt it because that is the next best thing after the $400 Juice Press, that presses your juice which you could have done manually by hand or even gotten a juicer and got fresh juice than packaged.

So, back on track it is surprising that while most apps still are a basic TableView or a TabView, we are writing boiler plate code to still make that work. In all fairness a TableView is not a ListView of the earlier years, but that is exactly how majority of apps are using it. Surprisingly, it still does not function well.

1. While the table view is used as a menu to get to the other sections of the app, developers might not want to have a highlight because the next screen is displayed either pushed or presented or even as a popup but when it is dismissed, it does not make sense to have the item highlighted. To remove highlighting the row, there are so many ways you can achieve it and each adds another complication or issue when used.

2. If the cell is a custom cell and it gets highlighted, the contents are not seen or obscured due to the highlight, again to fix that, there are several ways, from including removing the ability to highlight to changing the background view of the cell.

3. A custom tableView cell requires it to be registered to the table, however to connect the outlets, it needs a custom class. You cannot create a tableViewCell in a storyboard or if it is created in a tableView, then it cannot be reused with another tableView. Using xibs is an option, but why? When there is a storyboard, then why move it out.

4. The most common practice with developers is to add custom stuff on the tableView with Headers, stretchy headers, contracting headers, etc. Why does this not come out of the box, why does one have to write the code for estimatedRowHeight, estimatedSectionHeaderHeight, etc. Why can it not be as simple as a property that indicates that this is an expanding view with a dynamic height.

5. Why does table view not allow to create a Custom Header View in the Storyboard?

6. why does the tableView not have a property that says hideHeaderOnBlankSectionTitle than having to pass a height of 0.01 when the section title is blank



PART III - The Advance uses

Since the apps are now connected, i.e. need to be connected to a service online to provide details and functionality, the first screen that a majority of the users see is a Login Screen. There is nothing much to that other than the fact that it takes two pieces of information from the user, namely their username and the password and then logs them onto the online service which could be running ... (let's not get side-tracked). However, if the user does not have an account, then there needs to be a functionality to be able to sign-up. Which then asks a couple of more things than just the name and password. Since this is an input, we are talking of text boxes on the screen unless we use OCR and (... when we get to that in the future) Everytime we click on the textbox, the keyboard pops up. This keyboard is usually anything from half the screen height to a third of the screen's height. When the keyboard pops up, it obscures the fields. Developers have been writing code to solve this problem by moving the text boxes into a scroll view and scroll the view or allow the user to scroll it manually, or put them in a stack view and move the stack view frame via code. The simplest way is to add it into a tableView - However, the tableView does not have a defaultTextCell AND the tableView or for that matter any other view does not shift. Why can Apple not have a property on the view called sizeWithKeyboard as a Boolean, so as the keyboard appears, the bottomMargin of the view starts to reduce and when the keyboard starts to disappear, the bottomMargin starts to increase.

Apple give out awards for design excellence, it is a nice thing, it prompts developers and designers to aspire for that WOW factor. It has been seen in so many of the games. Note the last work in the sentence - GAMES. There are very few apps that have that, because most of the app requirements start with basic and the time is spent in writing the boilerplate code than doing something innovative. Specially when there are so many states that affect the elements on the screen and should size or move automatically. That's the reason for the interest of many developers towards React.

Part IV - Visual Basic

It is nearly the time for the end of this article, so if the mere mention of Visual Basic gets you, can't do much there, it would have been nice that you read the rest of the article than judging a book by it's cover, or in this case the content by the title. Which is strangely how many organizers of conferences do, they never read a pitch they look at the title and decide if it would be worth having for their conference.

Back to VB, While many debate the language and the issues that it had, similar to how Java is and how it has affected development by adding more complexities because the language could not manage things. The VB 6.0 IDE was in fact one of the best things ever.

Start a new project and run, you have a functional application. Drag Drop a couple of elements on the Form, double click and write code for the interaction with that element and done. All of the plumbing, connectivity, etc was done internally. You could simply drag drop a comboBox and a CommandButton onto the form and write code to populate the comboBox and then code that would read the index of the comboBox and display it in a messageBox when the commandButton was pressed. When you viewed the code, it was separated by a divider line and it was clear and concise (though majority of the developers wrote epics in there)

Development is a fun process, one that makes the developer feel good as they have created something, however there is something that is not right here because the average developer is stressed, not happy. A portion of that stress can be attributed to the Designers, which are also sub classified into several roles, the UX Designer, the UI Designer, the wireframe designer, the prototyper, etc. The IT industry is an industry that pays quite a lot for people that might not have the pre-requisite skills. A majority of Web Developers have turned Designers and then have turned into UX Designers, who may or may not understand the principles of UX, which is very beautifully captured by the fact that "U in UX is Users", so the experience should be based on the Users, not the designer that thinks it is them.

People will always want to customize, the basics should be encapsulated so that time can be spent on furthering it not starting from scratch.










Comments

Popular Posts