How do I open the calendar view at a specific row in a table (or any view, for that matter)

[swithp]

I am new to appsheet, so I may be missing the obvious…

I want to scroll through a calendar a year at a time, or open the calendar at a specific date.

The only built in scroll mechanism I have found in the calendar view works with increments of days, weeks, or months.

I expected to find a year scroller, and an arbitrary date picker to get to more distant dates quickly.

I tried to force the UX calendar view’s hand by creating a data slice for a particular year, hoping it would open within the selected year. It still opened at with the default view set to today().

Am I missing some mechanism within the UX to control where in a table a view is opened?

[WillowMobileSys]

Hi @swithp! Welcome to the AppSheet Community!

Unfortunately, the Calendar view is limited to your findings. It is still a “young” data control within the environment. AppSheet is somewhat developer-centric with their features. They will try to fold-in additional functionality based on developer requests and interest from among the community.

I encourage you to search the Feature Requests list to see if any requests have been submitted similar to your needs and if so vote them up. Or, if none found, then submit your own Feature Request.

[swithp]

Dear John,

Thanks for your reply. I’ll do a feature request as you suggested.

I am still experimenting to find out what I can achieve with AppSheet for a small charity

Aside from what it can and cannot easily do, what is holding me back from committing myself to building a complete app, is finding a “modus operandi” that allows me to build an app up from reusable parts. As I discover how to do each thing I need to be able to do to build the app I am planning. Currently I am not there, and have not found a way of developing, except starting from scratch each time, and having to rebuild by hand what I had working, and then getting the next new piece to work. If it doesn’t work out, then having to go back to square one again.

Part of the learning experience for me is discovering what function to do in the spreadsheet, and what to do in the app. For me it is complicated by my spreadsheet style, which is to used named ranges for everything. This allows me flexibility in modifying sheets (I typically string together named columns to perform lookups and the like e.g. {BankKey, BankTransaction, BankAmount}, that makes one part of the spreadsheet not dependent on the column order of another - very important with lookups of course). I also used named ranges (of one cell) for literal values, eg ca for “Current Account”, which means I can modify strings in the user interface from the use of those strings in formulae. If I was translating, it also would allow simpler translation. But it does not sit well with appSheet, which hates to find formulas in columns, even if those formula are only vales represented by a name. The other issue is that I want to use the same named ranges in appsheet, so that inserted “current account” in a cell can be =ca.

I will persevere, as I am finding appSheet a realistic approach to making mobile apps without committed to a lot of learning, and maintenance, and no skill apart from myself, for ongoing IT beyond spreadsheet skills.

Yours

Peter Swithinbank

[WillowMobileSys]

First, you can easily copy your apps from the MyApps page. On every app there a little collapsible menu. Tap it to expand and show other options at the app level.

One of those options is “Copy”. You can copy the app or both the app and the data (i.e. another sheet is created)

Unfortunately, there is not a way, at least that I know of, where you can build several apps all with different features and then later pick and choose those features to be combined together in a single app.

However, once you do have those pre-constructed features implemented and fine tuned, it isn’t to terribly difficult to use them as a reference on HOW to include them in a new app. It usually takes me only a half-hour or so for complicated features.

[Steve]

swithp:

a “modus operandi” that allows me to build an app up from reusable parts

Modularity and component reuse really aren’t a thing with AppSheet. The best you can do is copy entire apps.

swithp:

have not found a way of developing, except starting from scratch each time, and having to rebuild by hand what I had working, and then getting the next new piece to work. If it doesn’t work out, then having to go back to square one again

There is some very limited revision control if you want to undo a few recent changes. Your best bet is making a copy of the app before undertaking substantial changes.

swithp:

Part of the learning experience for me is discovering what function to do in the spreadsheet, and what to do in the app.

Although AppSheet has some support for spreadsheet formulas, you’re going to find development goes much smoother by minimizing or even eliminating functionality in the spreadsheet–at least until you’re comfortable with AppSheet. The spreadsheet really should just be a data store. You should definitely not be interacting with the spreadsheet as a spreadsheet.

swithp:

The other issue is that I want to use the same named ranges in appsheet, so that inserted “current account” in a cell can be =ca.

AppSheet doesn’t have a named-ranges equivalent. You could approximate it with slices, but it’s quite a bit different.

WillowMobileSystems:

Unfortunately, there is not a way, at least that I know of, where you can build several apps all with different features and then later pick and choose those features to be combined together in a single app.

Correct.

[swithp]

Dear John,

Thanks for your clear responses. There is nothing like listening to someone else to clarify ones own thoughts.

Your comment, to see the spreadsheet really as a backing store, and not part of the application, is really percipient.

I have a very complicated spreadsheet doing all the accounts and automating booking, banking, cash and asset reconciliation for the charity. It is all online, but not on mobile. A number of our users only have mobile, so I am working to shift the user facing parts to mobile, starting with hall booking.

Thanks to your comment I think rather than try and add mobile as a front end to the current booking sheet, I would be much better to develop the sheet and booking app on mobile separately, and then integrating the sheets using import. More like the way Google forms works, now I think about it.

Not only does it have the advantage of simplifying the development of the app, it also should dramatically improve sync performance, and the approach provides a way forward to develop the app in pieces, each piece having its own spreadsheet, and integrating at the spreadsheet layer.

Regards

Peter