Is anybody using TW on an Android device? We have a user who is using it but it will not display any external images, no matter what we try. We have read the thread on this in TW Talk but are getting no further.
Maybe message me to avoid cluttering up everybody’s feed.
Bobj
Hi Bob,
Android will not allow access to local file space in the normal way from a web browser, are these external images stored in a directory on the android device? If so then I know no direct way around this as it is a security feature so the solution is to install something like RCX which will serve local directories on a local network.
<figure>
{{JohnKFungHands2}}
<figcaption>//''Focused Fascial Breathing''//</figcaption>
<figcaption>//Breathe in through the nose to fill the Dantian. From the Dantian the breath follows the fasciae to reach and fill the hand. Breathe out by relaxing, and let the dissipating breath nourish the hand.//</figcaption>
</figure>
Tiddler JohnKFungHands2 then has content
<img src={{{ [{$:/info/url/protocol}prefix[content]then[http://127.0.0.1:8080/imagesExt/JohnKFungHands2.jpg]]:else[[imagesExt/JohnKFungHands2.jpg]] }}} >
In both cases Android and regular linux laptop the images are kept in a directory which is a sub directory of the directory that the tiddlywiki source file lives in. RCX serves the files on http://127.0.1:8080
Similar story for videos but there we can simply use the HTML5 option to include one source URI after another and the first that is accessible and playable will be selected.
I was going to suggest TidGi or Tiddloid as android TW apps.
@Ste_W , we are using Tiddloid.
What I find weird is that a wiki imported into Tiddloid shows external images perfectly ok, new tiddlers created in the wiki with links to external images do not show the images at all.
Bobj
You do need to detail how these external images are being accessed, external to the wiki but where? In the filesystem, on the internet etc…
Using @EricShulman amazing image fallback facility (see Fallback handling for $image widget), we have a simple work around for this limitation.
We store the folder for images on our server as well as allowing editors to have a local copy via dropbox (the arrangement is wikifile.html and Media folder at the same folder level in Dropbox).
@EricShulman 's clever code change now means that if an image is not found in the local Media copy, TW tries to download a copy from the server Media folder using a HTTP URL.
AND THIS WORKS!
Now the image quite happily appears in the tiddler on Android in edit mode running Tiddloid.
The code is simple.
\procedure displayIonly(imageTitle,imageWidth:"100%")
<$let
baseURL={{{ [{$:/TLS/onlineImages!!onlineimageURL}] }}}
onlineURL={{{ [<imageTitle>get[imageURL]] }}}
>
<$image source={{{ [<imageTitle>get[imageURL]] }}} width=<<imageWidth>> loading="lazy" >
<$image source={{{ [<baseURL>addsuffix<onlineURL>] }}} width=<<imageWidth>> loading="lazy" />
</$image>
</$let>
\end
$:/TLS/onlineImages!!onlineimageURL has the value “http://cultconv.neocities.org/ArtilleryRegister/”
The imageURL field is of the form “Media/State/image-0030.jpg”
Thanks again to @EricShulman for his clever code change which I hope will be part of the next version’s core.
The development team might want to consider a fallback like this for all external resource access.
bobj
I’m a heavy Tiddloid user, but I’m not using external images at all because all my wikis are encrypted and I know no way to have encrypted external images.
Yet I found the topic useful, especially that it contains an acknowledged working solution to a problem. It triggered my curiousity to the point that I’ve got myself involved by running a test to verify your claim: I had an empty wiki file, I imported it into Tiddloid, created a tiddler with a _canonical_uri field pointing to a local image file (I used a relative location as in a dir/imgfile.png in the same directory as the wiki HTML file) and saw the message that the external image can’t be loaded because the browser does not support it, after I saved the tiddler. Note that this is a third scenario, different than having an <img> HTML tag or an <$image> wikitext widget like other examples in this thread. Yet it’s likely that new users will end using this scenario, because searching for external images in TiddlyWiki docs gives an article that suggests using _canonical_uri.
I even suggest enhancing the title to make it more search friendly, by explicitly stating it’s about external images on Android when using Tiddloid.
To display external files correctly, it’s suggested to use a server to serve the tiddlywiki file. Like using round sync (a RCX fork) to serve as webdav to save tiddlywiki.
@XLBilly , our experience so far is that if you use the piggy backed image widget format as in my previous message, this obviates the need for any other software as the image file can be loaded directly from a server folder using a http url.
Although not tested, this piggybacked image widget structure should also support non Tiddloid users.
We use it on all images in our wiki so that if there is an issue with the local Media folder, images can still be displayed from server copies as long as Internet access is available, on all OS’s.
Bobj
What I find weird is that a wiki imported into Tiddloid shows external images perfectly ok, new tiddlers created in the wiki with links to external images do not show the images at all.
I use Tiddloid on Android to display local external images and didn’t encountered this problem. Not sure if this is helpful, I noted couple of differences in how images are display in my Tiddloid compared to yours :
My image URL is of the form “file:///storage/emulated/0/…full_image_path…/image-0030.png” (with all spaces in filename replaced by “%20”). I also use HTML native image definition "<img src="file:///storage/emulated/0/...full_image_path.../image-0030.png" /> instead of Tiddlywiki <$image source=... /> though I doubt that makes a big difference.
I tested on my Tiddloid. Canonical image tiddlers using full FILE URLs like “file:///storage/emulated/0/…full_image_path…/image-0030.png” will display the images (perhaps related to (2) below ?).
For my application, I have to use a variation of ximg macro to construct a full image URL on the fly to use TW on various OS platforms. I don’t use canonical images.
I use “Local (Legacy)” mode in Tiddloid. From Tiddloid FAQ : “… In the past 1.x days, Tiddloid use legacy file:// ways to handle files, causing the lack of access to cloud medias. Later I made another branch that implements Android’s SAF (i.e. Storage Access Framework), and finally it became a lightweight version…”.
I don’t use cloud storage, my images are fully local.
In the past, I do use single file TW on Android Chrome browser to display local external image, but there are so many security-related constraints, I have given that up. I believe there are less popular (older) Android browsers out there that are more compatible with Tiddlywiki, but each with their own set of compromises.
In Tiddloid, you can’t pinch-zoom an image beyond the physical screen size. You can do that if you open the TW file, close it and re-open it again. A useful bug for me.
At the moment, Tiddloid works well enough for me. In the future, I would like to look further into WebDAV server approach (RoundSync and the older RCX) and TidGi Mobile.
Thank you very much. I have tested your code on Tiddloid and it can display local pictures.