@vilc hi!
Has anything changed to the better with the new update?
1 Like
It’s better, because the system bars do not overlap with wiki (e.g. a bottom bar similar to notebook theme is not covered and therefore usable).
But there are still some issues:
- the top status bar is almost black with black icons, unreadable, didn’t test it with various system or wiki or TD themes/palettes yet
- the initial wiki view is weirdly scrolled so that the title is covered
- the main TD UI is being covered by system bars same as it was before
Tested on v0.0.3
Yes I need to test this on newer android versions than mine!
1 Like
It’s much better with the system bars on v0.0.5 now. The status bar and navigation bar don’t cover the UI anymore, and their colors respond to the wiki’s palette. The only issue that remains is that the wikis are opened a little bit scrolled down, so that the title is invisible and the subtitle is partially visible:
Hi @vilc ,
thanks for the feedback! Yes I’ve now tested on Android 16 to make sure everything works as expected.
The scrolled-down view at startup is TiddlyWiki5 specific. At startup of a wiki, TiddlyWiki5 scrolls the first tiddler in the story list into view, and in the shown case it’s the GettingStarted tiddler.
To solve such issues we’d need to create solid meaningful pull requests at the TiddlyWiki5 repository itself.
Could you please, if you find some time, test these points?
- fullscreen using the fullscreen button under “Tools” > should keep the navigation bar but hide the status bar. Keeping one of both bars is necessary so that drag&drop (in the “Open” tab for example) still works.
- changing a palette should tint navigation an status bar in the palette colours
- import of files (kept external by default) like images or videos, how is the User experience?
Thank you for your valuable time!
Simon
I understand about the initial scroll, thanks for clarifying.
Fullscreen looks as expected, drag and drop works (wow that’s nice to have on mobile):
Status and navigation bar react to palette. I would personally prefer both bars to take the background story river color. As of now, the bottom navigation bar takes the tiddler color, which looks strange on some palettes with high contrast between the bg and tiddler.
Importing images works smooth. The image is copied to wiki folder/attachments/ and a canonical URI refers to this new file. The only problem I see is that if multiple single file wikis are kept in the same TiddlyDesktop folder, then all the attachments from all wikis would be put together in the same folder. Is the behavior on desktop the same (sorry I’m not familiar with desktop TD that much)? Is it expected/recommended to keep each single file wiki in a different folder anyway?
Hi @vilc and thank you very much for testing!
Yes it’s expected to put all attachments into the same attachments folder if the wikis are all in the same directory. That avoids too much duplication of files. But you can however put - like you mentioned - each wiki in its own dedicated folder.
On desktop attachments work differently. There the attachments do not get copied, they simply get streamed to the wiki if they are kept externally. On Android it’s necessary to go the way of the “attachments” directory beneath the wiki file / folder, because the wiki there has access to files. It’s a workaround because of Android filesystem access limitations.
I’m so glad that it works for you!
Next update brings share files with wiki, open JSON, CSV, HTML and TID files with wiki, and a web clipper! So stay tuned 
Thank you,
Simon
4 Likes
Is there any chance we can get a native ‘Share-to’ android function that will trigger the import window on a selected TiddlyWiki with the ‘shared’ content?
That might be it’s own rabbit hole lol but I would love to be able to ‘share’ links, text messages, etc into TiddlyDesktop-RS to import as tiddlers.
Next release!
Not the messages sharing though. But come with ideas what could be shared with wikis!
Thanks,
Simon
1 Like
I’ve downloaded the v0.0.6 update. I tried sharing an image to a wiki, it worked as expected (image copied to attachments folder, canonical uri tiddler in wiki), but it was a bit strange that the drop down list of wikis to share with contained some that had been already deleted and not visible on the wiki list in the td-rs app. As if there was some cache or list of recent wikis that was different to the list of wikis shown in the app.
The release notes mentioned handling intent:// links. Could you give some example or point to a source of examples/syntax on how to use these? I have a brief idea of what the intents are in Android, but I’ve no idea how this could be used practically in TW.
Hi @vilc
Thank you for your bug report, I’ll fix it soon.
Here’s an example of the use of intents, it needs the pickaday plugin by @Mohammad installed:
\procedure time(suffix)
<$select tiddler={{{ [[$:/temp/calendar/]addsuffix<suffix>] }}} default={{{ [<suffix>match[start]then[0800]] :else[[0900]] }}}>
<$list filter="[range[6],[21],[1]]" variable="hour">
<$list filter="[range[0],[3]]" variable="step">
<$let minutes={{{ [<step>multiply[15]pad[2]] }}} time={{{ [<hour>pad[2]addsuffix[:]addsuffix<minutes>] }}} timeValue={{{ [<hour>pad[2]addsuffix<minutes>] }}}>
<option value=<<timeValue>>><<time>></option>
</$let>
</$list>
</$list>
</$select>
\end
<$edit-text tag="input" placeholder="Titel" tiddler="$:/temp/calendar/title" class="tc-calendar-title"/>
<br><br>
<$edit-text tag="textarea" placeholder="Beschreibung" tiddler="$:/temp/calendar/description" class="tc-calendar-description"/>
<br>
<$edit-text tag="input" placeholder="Ort" tiddler="$:/temp/calendar/location" class="tc-calendar-location"/>
<br><br>
Datum: {{||$:/plugins/kookma/pikaday/ui/buttons/TodoDueDate}}
Beginn: <<time start>>
Ende: <<time end>>
<$wikify name="wikifiedDescription" text='"""
{{$:/temp/calendar/description}}
"""'>
<$let startTime={{{ [{$:/temp/calendar/start}!match[]] :else[[0800]] }}} endTime={{{ [{$:/temp/calendar/end}!match[]] :else[[0900]] }}} title={{$:/temp/calendar/title}} description={{{ [<wikifiedDescription>encodeuricomponent[]] }}} location={{$:/temp/calendar/location}} start={{{ [{!!due}removesuffix[120000000]addsuffix<startTime>addsuffix[00000]format:date[TIMESTAMP]subtract[3600000]] }}} end={{{ [{!!due}removesuffix[120000000]addsuffix<endTime>addsuffix[00000]format:date[TIMESTAMP]subtract[3600000]] }}}>
<a href=`intent://calendar#Intent;
action=android.intent.action.INSERT;
type=vnd.android.cursor.item/event;
S.title=$(title)$;
S.description=$(description)$;
S.eventLocation=$(location)$;
l.beginTime=$(start)$;
l.endTime=$(end)$;
end;`>
Create
</a>
</$let>
</$wikify>
this example opens the calendar activity / intent and creates a calendar entry with title, description, location, start and end time. It’s not perfect because I had to subtract an hour manually from UTC time to match my timezone. I’d like to somehow automatically match the timezone… but anyway, you get the idea. There are many different intents one can create like that and launch by <a href="intent://...>launch</a>
2 Likes
Hi all,
the next Update of the Android App will bring “Real-time” sync over LAN to the App.
With that, two devices in the same network can sync wikis over WIFI for example.
An update made in one wiki will then almost instantly be reflected in the other connected wiki.
This works with the Android App and the TiddlyDesktopRS Desktop apps.
Further, the new Update brings some bug fixes and a significant faster startup time of wikis.
For those who are interested in testing, the test phase is still going and it’s still possible to opt in.
Who pays the cost of the app will be refunded right after, that’s how I handle it during the test phase.
Cheers,
Simon
2 Likes
Hello Simon,
Some first /early feedbacks:
Issues / unexpected behavior:
- About creating a new version
** You have to select twice the folder
*** You are firstly prompted for a name inside a folder view which let you think you can select the folder at this step
*** Then you are prompted to select the folder without taking into account the previous choice (and you are prompt for authorization even if this folder was previously authorized)
** fr-FR edition selection leads to an error (Failed to create wiki … boot.js:2267)
** Server edition leads to an "Internal Server Error : divide by zero
** 1st time I have selected the “Empty” edition it leads to the creation of a “tiddlers” folder only, I would have expected the creation of an html file
** I get the expected behavior in the following wikis test - About selecting the folder for the wikis
** It would be good to have an information / warning before creating a subfolder where it should / can not be installed (A subfolder in downloads is not possible / one in Documents is ok)
** Each time you do “Open a wiki file” you are prompted to authorize the use of the folder event if always using the same folder - When a wiki is open, clicking on the back button (<) is sometimes exiting the app instead of going back to the wikis selections page (I have not identified yet a pattern for this behavior)
What I really appreciate:
- The fact that the data is easily accessible in a standard folder
- The possibility to switch between a folder wiki and a single page wiki
- The possibility to select different editions and plugins when creating a new wiki
Open question:
- Would it be possible for the user to hide some items in the default editions and plugins selection
- And to add user defined edition and plugins
- Will there be any Tiddlyhost synchronisation workflow support (for instance, when creating a wiki, having a synchronisation button on each wiki in the wikis list)
BR,
Eskha
Hi @Eskha - yes these are the necessary steps to grant the App permission to the file AND the folder. Otherwise this won’t work.
I’ll investigate!
Did you click on “Open folder” or “Create new wiki file”?
Hmmm… not that easily
On the desktop app that works already, on Android I’ll have to think about it
Tiddlyhost should work from within the wiki. When you set it up, it should save your wiki both to Android and Tiddlyhost, same for GitHub, GitLab and Gitea savers.
Thank you,
Simon
@BurningTreeC Finally I was able to install the app. I would be interested to know whether support for third party cloud storages like onedrive will be supported
Hi @arunnbabu81
Support for third party cloud storage is not directly supported, there are workarounds with sync-apps that are available in the Play Store. They sync a local folder to your OneDrive for example. But no, direct support is not given.
1 Like
So what is the best way of syncing wikis between mobile phone and desktop using the android and desktop app created by yourself. How do you sync your wikis
I sync them over LAN-sync
You can activate LAN-sync in your Android app and the Desktop TiddlyDesktopRS app.
Then you pair the two devices once using the pairing code - show the code on one device, enter it on the other device.
Then you click the “Sync” button on one of your wikis and that wiki will show up as available for syncing on the paired devices.
Click on “Get wiki” on the paired device where you want to get the wiki, choose a folder where it should be saved.
It will then get the wiki, store it in that folder and open it.
Do one last thing if you want two-way-sync: on the device where you did “Get wiki” check the “Sync” button too.
1 Like
Thank you @BurningTreeC for your answers.
I have clicked on the “Create new wiki file”.
I was not able to reproduce the issue on the following tests.
I will try with Tiddlyhost saver. If I understand well the expected workflow (local editing ( remote publishing) is:
- create a TW in the app (~local TW)
- create a TW on TiddlyHost (~remote TW)
- Configure the local TW to save on the remote TW through the TiddlyHost saver
- While online save the local TW, it should both save locally and remotely.
- If going offline, saving only succeed locally
- going back online, saving again succeed both locally and remotely
Do I understand well the behavior / imagined workflow?
BR,
Eskha